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ABSTRACT 


This thesis reviews the Continuous Acquisition and Life-cycle Support (CALS) 
initiative and its data format specifications and analyzes how they were applied to the 
Evolved SEASPARROW Missile (ESSM) Program. The CALS initiative and its data 
format specifications were developed to facilitate management of defense system technical 
data. With recent reforms in defense acquisition policy called for in Secretary of Defense 
memorandum, “Specifications & Standards - A New Way of Doing Business” their 
application to defense system procurements has been questioned. 

Following a review of the CALS initiative and its data format specifications, an 
analysis of the application of the CALS initiative to the ESSM program is presented. 
Additionally, the information technology infrastructure at the Navy’s weapon system In- 
service Support Engineering Agent (ISEA), Port Hueneme Division, Naval Surface 
Warfare Center is presented, and analyzed on its suitability to handle CALS-compliant 
data formats. 

This research concludes that the CALS initiative and its data format specifications 
should be reviewed as to their application to the Engineering and Manufacturing 
Development phase contract of the ESSM Program. Furthermore, this research concludes 
that the information infrastructure at the ISEA is not fully prepared to handle technical 
data in CALS-compliant data formats. Finally, specific recommendations are made on 
how the Government should structure its Data Management Plan to convey to the prime 
contractor how it intends to manage technical data. 
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INTRODUCTION 


A. BACKGROUND 

This research emanates from the conflict between the defense acquisition 
manager’s desire for delivery of weapon system technical data in non-proprietary, open 
formats and recent changes in Department of Defense (DoD) acquisition policy. In the 
past, technical data such as engineering drawings, illustrations, and textual data for a 
weapon system was delivered to the Government in paper form. This made it necessary 
for DoD activities involved in managing the acquisition of a weapon system to orient their 
processes around handling paper-based documentation. These processes, however, were 
slow, error-prone and manpower intensive. 

In the mid 1980’s the DoD sought to capitalize on advances in computer hardware 
and in the areas of computer-aided design, computer-aided engineering, and concurrent 
engineering. DoD structured a series of military specifications and standards that 
facilitated the handling of weapon system technical data in open, digital formats. This 
initiative grew into a joint DoD-industry Continuous Acquisition and Life-cycle Support 
(CALS) initiative and led to acquisition processes between defense contractors and DoD 
acquisition managers being conducted with technical data in digital formats. With this 
change, there came a need for data management systems that could receive, store, and 
manipulate technical data in its various formats. Additionally, many of the acquisition 
management processes required “reengineering” using concepts such as Business Process 
Reengineering in order to truly reap the benefits of receiving, handling, and managing 
technical data in digital formats. 

With the recent changes in acquisition policy since Secretary of Defense, William J. 
Perry’s memorandum, “Specifications & Standards - A New Way of Doing Business,” the 
application of the CALS initiative and its data format specifications to DoD weapon 
system procurements is now in question. Specifically, Secretary Perry called for the “use 
of performance and commercial specifications and standards in lieu of military 
specifications and standards, unless no practical alternative exists to meet the user’s 
needs.” (DoD OSD, 1994, pg. 1) 
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B. THESIS OBJECTIVES 


The primary objective of this research is to determine whether the Continuous 
Acquisition and Life-cycle Support (CALS) initiative and its data format specifications 
should have been applied to the Engineering and Manufacturing Development (EMD) 
contract for the Evolved SEASPARROW Missile (ESSM) program. To achieve this 
objective, this research assesses: (1) the CALS initiative strategies, objectives and data 
format specifications, (2) how the ESSM program office applied the CALS initiative and 
their data format specifications, and (3) the information technology (IT) infrastructure at 
the Navy’s weapon system In-service Support Engineering Agent (ISEA), Port Hueneme 
Division, Naval Surface Warfare Center (PHD-NSWC). 

C. RESEARCH QUESTIONS 

This thesis attempts to answer the following research questions: 

1. Primary Research Question 

Should the CALS initiative and its data format specifications have been applied to 
the ESSM program’s EMD phase contract? 

2. Secondary Research Questions 

• Is the IT infrastructure at the ESSM ISEA adequate to support the 
management of the technical data for the Evolved SEASP ARROW Missile 
during the life-cycle of the weapon system? 

• How could the ESSM program office structure the Data Management Plan for 
the EMD phase contract to convey to the prime contractor how the 
Government intends to manage the technical data associated with the weapon 
system? 

D. SCOPE OF THESIS 

This thesis analyzes the CALS initiative and its new strategies and objectives made 
public in October 1993. It also presents the two “flagship” CALS infrastructure 
modernization systems Joint Computer-aided Acquisition and Logistics Support (JCALS) 
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and Joint Engineering Data Management Information Control System (JEDMICS) and 
analyzes the four CALS Data Format Specifications. 

The Navy’s ESSM program’s efforts to apply the CALS initiative and its data 
format specifications will be presented through the acquisition planning and source 
selection phases of the program. This thesis does not address how the ESSM program 
intends to implement the CALS initiative during management of the ESSM EMD phase 
contract. Instead, it offers recommendations on how the Government should structure its 
data management plan to ensure complete coverage of all relevant technical data issues 
with the prime contractor. 

This thesis includes an analysis of the information technology infrastructure at the 
Navy’s ISEA for surface ship weapon systems, PHD-NSWC. The focus is on whether 
PHD-NSWC is capable of performing its functions as the ISEA for the ESSM if the 
contractor-delivered technical data is in CALS-compliant technical data formats. 

E. LITERATURE REVIEW AND RESEARCH METHODOLOGY 

The research on the CALS initiative is primarily a review and analysis of CALS 
documents that have been issued by the DoD CALS Policy OflBce. Department of Navy 
activities that have responsibility for interpreting the CALS initiative and providing 
implementation guidance on the initiative for Navy and Marine Corps activities is also 
reviewed and analyzed. Additional insight into how the CALS initiative and its principals 
are being implemented in defense systems by the U.S. DoD, foreign DoDs, and by 
numerous domestic and international defense contractors was gained from attendance at 
the seventh annual CALS Conference and Exposition December 7-9, 1994 in Long Beach, 
CA. The information on the ESSM Program is drawn from documentation on the 
program provided by PHD-NSWC and from interviews with PHD-NSWC’s ISEA 
representative for ESSM. The analysis of the IT infi-astructure at PHD-NSWC was 
obtained during three separate visits to Port Hueneme. It is based on open observation of 
the work environment at PHD-NSWC, direct interaction with the Joint Computer-aided 
Acquisition and Logistic Support (JCALS) system, and observation of the Integrated Data 
Management System (IDMS) during a demonstration. 
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F. CHAPTER OVERVIEWS 

This thesis is organized in six chapters. The following is an overview of the 
remaining chapters. 

Chapter II, “Continuous Acquisition and Life-cycle Support Initiative,” presents 
this joint DoD-industry initiative and the two implementations under its infrastructure 
modernization strategy. Chapter III, “CALS Data Format Specifications,” describes the 
four data format specifications that have been created under the CALS initiative. Chapter 
IV, “Evolved SEASPARROW Missile Program,” presents an overview of the Navy’s 
plans to acquire an upgrade to the RIM-7P surface-to-air missile. Chapter V, 
“Information Technology Infrastructure at the In-service Support Engineering Agent,” 
describes PHD-NSWC’s current technical data management system and plans to integrate 
that system with portions of the JCALS system. Finally, Chapter VI, “Conclusions and 
Recommendations for the Management of Technical Data for the ESSM Program,” 
presents several conclusions drawn from this research and discusses issues requiring 
further research. This chapter also offers recommendations on how issues related to the 
management of ESSM technical data should be described by the Government to potential 
contractors. 

G. ACRONYMS 

This thesis contains numerous acronyms throughout each of the chapters. Listed 
below are some of the most frequently used acronyms; 


CALS 

Continuous Acquisition and Life-cycle Support 

CDRL 

Contract Data Requirements List 

CGM 

Computer Graphics Metafile 

CITIS 

Contractor Integrated Technical Information Services 

COTS 

Commercial Off-The-Shelf 

DMP 

Data Management Plan 

DoD 

Department of Defense 

DoN 

Department of the Navy 

EMD 

Engineering and Manufacturing Development 

ESSM 

Evolved SEASPARROW Missile 
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GCO 

Government Concept of Operations 

GFI 

Government Furnished Information 

GOTS 

Government-Owned Software 

IDMS 

Integrated Data Management System 

IGES 

Initial Graphics Exchange Specification 

ISEA 

In-service Support Engineering Agent 

IT 

Information Technology 

JCALS 

Joint Computer-aided Acquisition and Logistics Support 

JEDMICS 

Joint Engineering Data Management Information Control 
System 

MAPP 

Master Program Plan 

NAVSEA 

Naval Sea Systems Command 

PHD-NSWC 

Port Hueneme Division, Naval Surface Warfare Center 

PM 

Program Manager 

RFC 

Request For Comment 

RFP 

Request For Proposal 

SGML 

Standard Generalized Markup Language 

SoW 

Statement of Work 
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II. CONTINUOUS ACQUISITION AND LIFE-CYCLE SUPPORT (CALS) 

INITIATIVE 

This chapter begins by providing background information on the CALS initiative 
and then describes the current DoD CALS strategic goals. Next, organizations affiliated 
with CALS and the documentation associated with CALS are presented. These are 
followed by the CALS implementation strategies and acquisition process guidance. This 
chapter concludes with descriptions of the two “flagship” CALS initiative 
implementations: the Joint Continuous Acquisition and Logistics Support (JCALS) 
program and the Joint Engineering Data Management Information Control System 
(JEDMICS). 

A. BACKGROUND 

This background information is taken from Annex 1 of the CALS Strategic Plan 
published by the DoD CALS & EDI (Electronic Data Interchange) Office in October 
1993. 


1. CALS Origins 

In the mid 1980’s, the DoD instituted the Computer-Aided Logistics Support 
(CALS) initiative as an effort to standardize how technical information should be managed 
within the department. Advances in computer-aided design, computer-aided 
manufacturing and computer-aided engineering led defense logisticians to move away 
from a paper-based technical documentation system to a system where technical 
information is created, managed and distributed in digital forms. It was thought that the 
CALS initiative could help the DoD reduce its costs for acquiring technical documentation 
while making it more accurate, current and timely. In its beginnings, CALS primarily dealt 
with the logistics of support documentation. 

2. CALS Evolution 

As the benefits of the CALS initiative became better known, DoD acquisition 
managers sought to incorporate CALS concepts into weapon systems procurements. In 
1988, CALS was renamed the Computer-aided Acquisition and Logistics Support 
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initiative. This better reflected its use in managing the technical information associated 
with weapon system acquisition. 

Developments in the field of Concurrent Engineering (CE) eventually led the 
CALS initiative to encompass all aspects of weapon system acquisition; design, 
production and logistics support processes. Similarly, advances in telecommunications 
such as enterprise networking and digital information exchange protocols led to more 
technical documentation to be exchanged between businesses. Terms such as electronic 
commerce and electronic data interchange soon became associated with CALS. 

3. CALS Today 

Now renamed Continuous Acquisition and Life-cycle Support, the CALS initiative 
has been expanded from its roots in technical documentation and logistics support to CE 
and integrated business processes. It has gained acceptance outside the DoD and defense 
industries to become a joint DoD-industry managed initiative. The CALS initiative has 
also been accepted and implemented within international defense departments in Canada, 
Europe, Asia, and Australia. 

4. CALS Vision 

The CALS Industry Steering Group has promulgated a vision statement that is 
quoted below. It was taken from the conference guide to the seventh annual “CALS Expo 
94 International” Conference and Exposition. 

The Vision is for all or part of a single enterprise (e g., an original 
equipment manufacturer and its suppliers, or a consortium of public and 
private groups and academia), to be able to work from a common digital 
data base, in real time, on the design, development, manufacturing, 
distribution and servicing of products. The direct benefits would come 
through substantial reductions in product-to-market time and costs, along 
with significant enhancements in quality and performance. 

B. STRATEGIC GOALS AND OBJECTIVES 

The strategic plan is intended to expand upon the CALS Vision. Each of the three 
strategic goals and their supporting objectives is quoted below in italicized text and is 
elaborated upon in plain text. 
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1 . 


Strategic Goal 1 


Expand DoD ’5 relationship with industry to adopt more harmonious methods of 
operation and data exchange. This goal describes the DoD’s desire to work more closely 
with our nation’s defense industrial base for weapon system procurements. In the past the 
DoD has relied heavily on military specifications and standards to direct contractors on 
how to deliver a product. With reduced levels of funding for defense acquisitions today, 
the DoD is seeking to substitute commercial equivalents for military needs whenever 
possible. This change places more trust on our defense industrial base to recommend 
industry standards in response to Requests For Comments (RFCs) and Requests For 
Proposals (RFPs). 

a. Objective lA 

Develop a DoD and industry infostructure. Development of a common 
means of exchanging digital information between the DoD and industry is intended to 
integrate combat units with the defense industry. The architecture for this capability is 
being developed in concert with Command, Control, Communications, and Intelligence 
(C3I) planners within the Pentagon. 

h. Objective IB 

Enable “dual use ” technologies. “Dual use” technologies refer to industry 
or commercial products that fulfill military needs. The hope is that innovative commercial 
products will be delivered to combat forces more rapidly and at a lower cost to the DoD. 

c. Objective 1C 

Harmonize standards and practices. When the DoD feels the need to 
publish a military specification or standard, it currently submits it to industry groups and 
national and international standards organizations for comments. The goal is to have all 
possible military specifications and standards relating to information technology migrate to 
Federal Information Processing Standards (FIPS) or international standards in the fixture. 
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d. Objective ID 

Provide CALS expertise through education and training. The Defense 
CALS Executive is tasked to provide CALS implementation guidance for users and 
industry alike. Federal agencies such as the Department of Commerce (DoC) and the 
Advance Research Projects Agency (ARPA) are to assist the DoD in developing CALS 
curricula for entities such as small business defense contractors and academia. 

2. Strategic Goal 2 

Complete the transition of DoD's active information and business transactions to 
standard electronic formats. This goal describes the need for the DoD to abandon paper- 
based systems for technical documentation and logistics support in favor of digital data 
formats. Documentation required for the management of weapon systems acquisitions 
should be digitally encoded and simultaneously available to the DoD Program Executive 
Office and the defense primary and sub contractors. 

fl. Objective 2A 

Modernize DoD hardware and software. This objective describes the 
transition from filing cabinets in DoD offices to computer workstations on every desk. As 
hardware and software is purchased for CALS-compliant purposes, adherence to open 
standards is mandatory. 

b. Objective 2B 

Acquire new data in digital form. Acquisition of new data in digital form 
requires the procuring military department or agency to have procedures in place for 
handling the digital data. Existing procedures for the handling of paper-based 
documentation will be insufficient for the manipulation and management of data in digital 
formats; these procedures must be reconsidered. 

c. Objective 2C 

Convert existing data to digital form. Paper-based legacy data must be 
evaluated for the cost effectiveness of its conversion to digital form. For weapon systems 
expected to remain in the inventory for years to come, conversion of their documentation 
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to digital formats must be done with an eye toward which digital formats are most widely 
accepted and most robust for future needs. 

d. Objective 2D 

Conduct business transactions in digital form. This objective is directed 
toward conducting defense acquisitions within the guidelines of Electronic Commerce 
(EC) using Electronic Data Interchange (EDI) standards. It is anticipated that this 
objective will lead to quicker turn-arounds on management decisions for acquisition 
managers. 

3. Strategic Goal 3 

Continue progress toward integration of DoD's digital information. This goal 
addresses the need for the DoD to be able to digitally share all information concerned with 
a weapon system \vith acquisition managers, contractors, logistics support personnel and 
end-users. The intent is to develop an Integrated Weapon System Data Base (IWSDB) as 
the repository for all data elements of a particular weapon system. Much fundamental 
research must be conducted to develop a data model, proper access restrictions and 
security protections for such a data base. 

a. Objective 3A 

Develop an integrated infostructure. This objective calls for the 
development of a standard for digital information exchange. Without efficient information 
sharing, management of business processes cannot effectively begin. The DoD is actively 
working with industry and national and international standards organizations to develop a 
digital information exchange standard that will adequately handle the requirements for a 
system that is expected to have a long life-cycle. 

b. Objective 3B 

Align defense integrated infostructure with the national information 
infrastructure. The National Information Infrastructure (Nil) or “information 
superhighway” is in the conceptual stages with various federal agencies and the private 
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sector. The DoD must remain cognizant of the progress in defining the Nil so that it may 
seamlessly integrate with it should the need arise in the fiiture. 

c. Objective 3C 

Promote business process reengineering. Business Process Reengineering 
(BPR) was first introduced to the DoD in the Corporate Information Management (CIM) 
initiative in the late 1980’s. As the DoD attempts to move away from managing paper- 
based systems to managing information digitally, it must avoid the urge to simply 
automate what perhaps is a bad process through the application of computer technology. 
Much effort must be conducted in the fields of workflow management, workgroup 
computing and business process reengineering to ensure that DoD agencies and military 
departments are prepared for the new ways of managing information. 

C. CALS ORGANIZATIONS 

This section describes the various government, industry and international 
organizations that participate in the CALS initiative. 

1. Government 

a. Department of Defense 

Within the Department of Defense (DoD), the CALS initiative is managed 
by the CALS & EDI Office within the Office for the Under Secretary of Defense 
(Acquisition and Technology). This office is responsible for issuing CALS directives and 
coordinating CALS efforts among DoD military departments and agencies. The CALS & 
EDI Office is the point-of-contact for CALS issues when interacting with other federal 
agencies. 

The Defense Information Systems Agency (DISA) Information Processing 
Directorate maintains the Center for Standards (CFS) as the DoD’s repository for 
information processing standards. The CFS is authorized and responsible for adopting, 
developing, specifying, certifying and enforcing information processing standards for the 
DoD. 
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b. Department of the Navy 


Each military department has a representative within the CALS and EDI 
Office and uses smaller entities to manage the CALS initiative. Within the Department of 
the Navy (DoN), the Naval Air Warfare Center, Naval Surface Warfare Center and Naval 
Undersea Warfare Center all have divisions that participate in the CALS initiative to 
varying degrees. The Carderock Division of the Naval Surface Warfare Center is the 
repository for CALS standards and the lead testbed for the CALS Test Network within 
the DoN. 

The Naval Air Warfare Center, Aircraft Division, Indianapolis, IN and the 
Naval Surface Warfare Center, Crane Division, Louisville, KY and Crane, IN 
cooperatively maintain the CALS Resource and Implementation Cooperative (RIC). The 
RIC was established as the primary source for technical guidance for naval forces 
attempting to implement or apply the CALS initiative. 

c. Federal Agencies 

Besides the DoD, other federal agencies, such as the Department of 
Commerce (DoC) and the Advance Research Projects Agency (ARPA) have roles and 
responsibilities in the CALS initiative. 

The National Institute of Standards and Technology (NIST), a part of the 
DoC, has been tasked to provide the DoD assistance in developing the CALS standards. 
NIST works with military departments and agencies, industry and national and 
international standards organizations to develop the CALS initiative standards and to 
make recommendations to the CALS and EDI Office on which standards to implement. 
Additionally, NIST through the Manufacturing Extension Partnership maintains thirty-six 
Manufacturing Extension Centers that help small-to-medium-sized manufacturers increase 
their international competitiveness. (Snodgrass, 1994, pg. 13) 

The DoC’s National Technical Information Service (NTIS) is the central 
repository for over 1,000 CALS documents. These documents are available through File 
Transfer Protocol (FTP) at Internet host address 192.239.92.203, by modem on 
FedWorld Bulletin Board System (BBS) at 1-703-321-8020 and voice telephone at 1-703- 
487-4823 (information) and 1-703-487-4650 (ordering). 
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ARPA manages the Electronic Commerce Resource Centers (ECRC) ^ 
which assist small manufacturers with CALS concepts and strategy by providing education 
and training. The ECRC will go as far as to visit manufacturers and conduct business-case 
analysis to determine return on investment on implementing CALS concepts. (Snodgrass, 
1994, pg. 13) 

2. Industry 

The CALS initiative being a joint DoD-industry program, is primarily represented 
by the CALS Industry Steering Group (ISG). The CALS ISG leadership has recently 
renamed the CALS initiative to Commerce at Light Speed to better reflect the ISG’s 
opinion that CALS strengths rest with Enterprise Integration (El) efforts in 
manufacturing. (Snodgrass, 1994, pg. II) 

The CALS ISG has formed Regional Interest Groups (RIGs) to meet periodically 
with industry representatives to keep them current with the latest CALS developments. 
At the time of this writing there are CALS RIGs in at least 25 states. (Snodgrass, 1994, 
pg- 13) 

For the purposes of providing individuals the opportunity to comment on CALS 
standards and specifications, the CALS ISG maintains a BBS. This BBS serves as a 
means for distributing of CALS documents and as a forum for submitting comments on 
proposed standards and specifications. The number for the BBS is 1-703-321-8020 for 
modem access. (Smith and Ellis, 1994, pg. 10) 

3. International 

At the seventh aimual CALS conference and exposition on December 6, 1994, the 
CALS ISG Executive Advisory Council announced the formation of CALS International. 
CALS International will serve to advance international business by promoting the use of 
standards and shared digital data in electronic commerce. Presently, there are nine nations 
with CALS ISG organizations: United States, Canada, United Kingdom, France, 
Germany, Sweden, Japan, Taiwan, and Australia. Additional countries are expected to 
formalize a CALS organization with the announcement of CALS International. 


^ These centers were formerly know'n as CALS Shared Resource Centers (CSRC). 
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The CALS International will consist of three elements: 

• An International Board of Directors, responsible for setting priorities, defining 
long-range objectives and forging strategic partnerships and cooperative 
relationships; 

• The International CALS Congress, responsible for developing a coordinated 
approach to implementing CALS requirements; and 

• The International CALS Secretariat, responsible for providing staff support. 

D. CALS DIRECTIVES, GUIDANCE AND STANDARDS 

This section will describe the documentation associated with the CALS initiative. 

1. Directives 

Usage of CALS for the acquisition of new weapon systems and major equipment 
was first mandated in August 1988 by the Deputy Secretary of Defense in a memorandum 
to military department secretaries and the director of the Defense Logistics Agency. 
Citing that “CALS standards will enable either digital data delivery or government access 
to contractor-mmntained technical data bases,” CALS standards were specified for two 
types of acquisition scenarios: 

• For systems now in full-scale development or production, program managers 
shdl review specific opportunities for cost savings or quality improvements 
that could result from changing weapon system paper deliverables to digital 
delivery or access using the CALS standards. 

• For systems entering development after September 1988, acquisition plans, 
solicitations, and related documents should require specific schedule and cost 
proposals for: (1) Integration of contractor technical information systems and 
processes; (2) Authorized government access to contractor data bases; (3) 
Delivery of technical information in digital form. 

This memorandum (since canceled) was later codified in the Defense Federal 
Acquisition Regulation Supplement (DFARS). DFARS tasks acquisition managers and 
program offices for planned acquisitions to: 
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• Implement CALS standards in new defense system acquisitions with CALS 
requirements being incorporated in the Requests For Proposals (RFPs) and 
eventually the contracts; 

• Describe the extent of how the CALS standards have been implemented in 
their acquisition planning; 

• Ensure that their offices have the sufficient computer technology infrastructure 
in place and are capable of receiving and managing digital data. 

For weapon systems already in the DoD inventory, DFARS requires managers to 
“exploit” the CALS standards by converting existing paper-based technical data to digital 
data. This requirement is made with the understanding that the program’s phase, type, 
size and duration should be the overriding consideration before proceeding with any 
conversion. 

Two other directives relating to the CALS initiative, both titled Computer-aided 
Acquisition and Logistics Support, include OPNAVTNST 4120.5, dated I July 1992 and 
SECNAVINST 5000.2A, dated 9 December 1992 with Change 1 dated 26 February 1993. 
The Defense Acquisition Board, Logistics Review Groups, Major Automated Information 
System Review Council, and other unspecified oversight activities are tasked by the 
DFARS to review and audit defense acquisition managers for compliance with DoD and 
DoD component CALS policy. 

On June 29, 1994, Secretary of Defense William J. Perry issued a memorandum to 
the Secretaries of the Militaiy Departments and the Directors of the Defense Agencies 
directing that “performance specifications shall be used when purchasing new systems, 
major modifications, upgrades to current systems, and nondevelopmental and commercial 
items, for programs in any acquisition category. If it is not practicable to use a 
performance specification, a non-government standard shall be used.” Secretary Perry 
allowed the use of military specifications and standards in cases where performance 
specifications or non-government standards are not cost effective. But a waiver for their 
uses must be granted by the Milestone Decision Authority (MDA) for the defense 
program. The memorandum went on to state that military specifications and standards 
listed in the DFARS, such as the CALS initiative’s military specifications and standards, 
are no longer mandatory and should be viewed as only guidance by program managers. 
(DoD OSD, 1994, pg. 2) 
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2 . 


Guidance 


This section will describe the two guides applicable to Department of the Navy 
acquisition managers. Both are available in digital form from the NTIS. 

a. DoD CALS Implementation Guide 

The DoD Implementation Guide for CALS is a Military Handbook (MIL- 
HDBK-59B) prepared by the DoD CALS & EDI Office with the assistance of the military 
departments, federal agencies and the defense industry. Applicable to all the military 
departments and DoD Agencies, this handbook addresses; 

• CALS strategy; 

• DoD CALS policy; 

• Acquisition process guidance; 

• Special considerations for existing defense systems; 

• Infrastructure modernization. 

b. Navy/Marine Corps Manager’s Desktop Guide for CALS 
Implementation 

This guide in its third edition dated 30 September 1994, is produced by the 
Navy CALS Resource and Implementation Cooperative (RIC) at the Naval Air Warfare 
Center, Aircraft Division, Indianapolis. At over 450 pages in length, it provides invaluable 
guidance for DoN activities seeking information about the CALS initiative and its 
standards and specifications. 

3. CALS Standards and Standardization Documents 

To achieve the goal of digital data interchange, definition of data standards is 
considered a necessity. The CALS policy is to adopt private sector (i.e., non-government) 
data standards, which are anticipated to have long life-spans. The definition of the data 
storage and retrieval system, which is anticipated to have a shorter life-span, is left to 
users. This section discusses the differences between a CALS Standard and a CALS 
Standardization Document. It concludes with a discussion of the standardization process. 
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CALS Standards 


a. 

A CALS Standard is considered to be a non-government data standard that 
is approved by a standards-setting organization such as the American National Standards 
Institute (ANSI) or the International Standards Organization (ISO). These standards are 
intended to function at the Presentation Layer and Application Layer of the Open Systems 
Interconnection (OSI) Reference Model. Examples of CALS Standards include; 

• ANSI Y14.26M, Initial Graphics Exchange Specification (IGES); 

• ANSI X3.122, Computer Graphics Metafile (CGM); 

• ISO 8879, Standard Generalized Markup Language (SGML). 

b. CALS Standardization Documents 

CALS Standardization Documents are the DoD interpretations and 
implementations of a non-government data standard. Examples of CALS Standardization 
Documents include: 

• MIL-D-28000, Digital Representation for Communication of Product Data; 
IGES Application Subsets; 

• MIL-D-28001, Markup Requirements and Generic Style Specification for 
Electronic Printed Output and Exchange of Text; 

• MIL-R-28002, Requirements for Raster Graphics Representation in Binary 
Format; 

• MIL-D-28003, Digital Representation for Communication of Illustration Data: 
CGM Application Profile. 

These Standardization Documents will be explained in greater detail in the 
next chapter, “CALS Data Format Specifications.” 

c. Standardization Process 

The practice of the DoD to use a non-government standard in the CALS 
initiative stems from the desire to reap the benefits of using recognized standards with an 
installed base of users. The hope is this criterion will ensure a wide choice of 
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implementation tools and the resultant reduction in procurement and life-cycle costs for a 
system. 

The DoD chooses CALS standards from the following organizations that 
are listed in decreasing order of preference: 

• International standards body such as the International Standards Organization 
(ISO); 

• National standards body such as the American National Standards Institute 
(ANSI); 

• Industry professional society such as the Institute of Electrical and Electronic 
Engineers (IEEE); 

• A de-facto industry standard if no other choice is available. 

The DoD and the defense industry have agreed upon a six-step process to 
select and implement a standard for the CALS initiative. In practice for over three years, 
these steps are listed below (Smith and Ellis, 1994): 

1. Identify the standardization requirement; 

2. Initiate a standardization project; 

3. Develop the necessary standardization document; 

4. Coordinate the draft standardization document; 

5. Resolve any comments generated by the coordination review; and 

6. Publish the approved standardization document. 

E. IMPLEMENTATION OF THE CALS STRATEGY 

The Department of Defense’s goal for the CALS strategy, as described in MIL- 
HDBK-59B, is transition of weapon system acquisitions from a paper-based system to one 
where all technical data is in digital formats and managed automatically. The envisioned 
implementation of this goal is the Integrated Weapon Systems Data Base (IWSDB). In 
the IWSDB all technical data related to a weapon system is logically stored in one data 
base. This logical data base is accessible to the DoD acquisition managers, contractors 
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and their sub contractors, DoD logistics support activities, and the end users. (DoD 
CALS Office, 1994, pg. 4) 

The remainder of this section describes the four target areas in a weapon systems 
life-cycle that need to be addressed for implementation of the CALS strategies and 
objectives. This section concludes by presenting acquisition process guidance for weapon 
system acquisition managers who intend to implement CALS strategies and objectives. 

1. Target Areas for Implementation of the CALS Strategy 

This section presents the four areas during a typical weapon system’s life-cycle 
that require attention when attempting to implement the CALS strategy. 

a. Infrastructure Modernization 

Infrastructure modernization refers to removing filing cabinets, typewriters, 
printing presses, copier machines and replacing them with computer and 
telecommunications technology. This strategy must be pursued within the requirements of 
existing Federal Information Processing Systems (FIPS) guidance and should follow an 
open-system, scaleable, standards-based architecture. This strategy is being achieved by 
two methods: 

1. Development of a Joint Service system that has the target architecture; and 

2. Migration of existing systems to the CALS requirements through modification 
and upgrades. 

h. Process Improvement 

Process improvement indicates the need for examination of current 
practices with paper-based acquisition procedures and evaluating whether the procedures 
are still valid in an automated acquisition environment with digital data. Reengineering 
and business process improvement are some of the techniques that will need to be used to 
avoid the temptation of simply automating what may be a faulty process. 

c. Digital Data Acquisition 

Acquisition of digital data is the bold step of accepting technical 

documentation of a weapon system in digital formats rather than in “camera-ready copy” 
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or “final reproducible copy” formats. Interchange and exchange of digital data over a 
variety of computer systems will require standardization of digital data formats and data 
interchange procedures. 

d. Integration 

This fourth target area for implementation is the definition of a logical data 
structure for all weapon system information. This will ensure all related data will be 
maintained in a common data base, such as the fWSDB concept, over the life-cycle of that 
weapon system. (DoD MIL-HDBK-59B, 1994, pp. 4-5) 

2. Acquisition Process Guidance 

This section describes how the CALS strategies and objectives are implemented in 
the acquisition of a typical defense system. 

a. Acquisition Planning Process 

The Defense Federal Acquisition Regulation Supplement (DFARS) Part 
207.105 requires the acquisition plan for a weapon system to include a description of how 
the CALS initiative has been incorporated in life-cycle cost considerations. The 
acquisition plan should include the program’s strategy for acquiring and managing the 
technical data associated with a weapon system in digital formats. Since each weapon 
system procurement has unique technical data and information requirements, the program 
office in their strategy for digital data acquisition and management, should address the 
following issues: infrastructure, data access, data management, data flow, and data 
exchange. (DoD CALS Office, 1994, pg. 9) 

The CALS Government Concept of Operations (GCO) is a document 
prepared by the weapon system program office during the acquisition planning process. It 
describes to potential offerors what the iiffiastucture and CALS implementation strategy 
will be for the particular weapon system program. The GCO is usually prepared once the 
program office has received inputs from all the defense activities expected to support the 
weapon system during its life-cycle. It is included as Government Furnished Information 
(GFI) within the Request For Proposal (RFP). 
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Specific guidance for developing a GCO and a sample questionnaire is 
contained in MIL-HDBK-59B, Annexes E and F. The major points of a GCO may 
include: 

• Identification of data type deliverables; 

• Identification of data users; 

• Identification of data use and processing; 

• Identification of data user infrastructure; 

• Identification of data delivery and type; 

• Identification of data format; 

• Identification of data interchange standards; and 

• Determination of mechanism and types of media for data delivery and access. 

b. Solicitation and Selection Process 

Completion of the acquisition process planning stage and formulation of a 
CALS Government Concept of Operations firmly grounds the weapon system acquisition 
management team in the CALS principals as it enters the solicitation and source selection 
process. During the solicitation and selection process, the most critical element is for 
acquisition managers to communicate their CALS implementation strategy in the RFP. 
MIL-HDBK-59B contains explicit examples of how CALS language may be incorporated 
in an RFP in order that the potential offerors understand exactly how CALS principals will 
be implemented in this particular weapon system program. 

Section L of a RFP contains the Instructions to Offerors (ITO). This 
section is used to instruct potential bidders to submit a Contractors Approach to CALS 
(CAC). The CAC is a comprehensive document detailing the contractor’s “approach, 
experiences, and successes in the creation, management, use, and exchange of digital 
information” (DoD CALS Office, 1994, pg. 22). This document can be useful to the 
program office in evaluating the contractor’s capabilities to create and manage digital data 
as specified in the RFP. This section may also be used to solicit alternative proposals from 
potential contractors such as alternate delivery methods of data requirements specified in 
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the RFP. These alternate proposals should be aimed at reducing life-cycle costs for the 
weapon system and thus must be submitted with supporting cost and benefit justification 
information. (DoD CALS Office, 1994, pg. 23) 

c. Implementation Process 

The implementation process for the CALS strategy involves a three-part 
approach: on-line services; digital data delivery; and integration of product, process, and 
data. The implementation process encompasses the input of specified data elements from a 
weapon system contract. The data elements are developed using CALS military 
standards; data format specifications; and product, process and data integration standards. 
These are provided in a CALS/Concurrent Engineering environment to yield CALS digital 
data products useful for the weapon system’s life-cycle. (DoD CALS Office, 1994, pg. 
24) 

F. CALS INFRASTRUCTURE MODERNIZATION SYSTEMS 

This section describes the two “flagship” CALS systems: Joint Computer-aided 
Acquisition and Logistics Support (JCALS) and the Joint Engineering Data Management 
Information and Control System (JEDMICS). 

1. Joint Computer-aided Acquisition and Logistics Support 

The CALS implementation target area, infrastructure modernization, has been 
realized in the Joint Computer-aided Acquisition and Logistics Support (JCALS)^ 
Program. The JCALS concept originated from the US Army’s Technical Information 
Management System (TIMS), which became the Army CALS (ACALS) program in 
March 1987. In January 1991, the Army was directed to transition ACALS, already in 
Phase I of its development by Computer Sciences Corporation (CSC) of Moorestown, NJ, 
to include joint requirements and to make it a joint program. The Joint CALS concept 
was demonstrated by two contractors in February 1991 and was designated a joint service 
program in October 1991. CSC was awarded the JCALS contract, valued at $ 744 million 

2 Although the DoD has changed the CALS to Continuous Acquisition and Life-Cycle Support, the 
JCALS Program Office has retained the older meaning for CALS, Computer-aided Acquisition and 
Logistics Support. 
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if all options are exercised, in December 1991 (Zurier, 1993, pg. S4). The program is 
currently in Phase III. The remainder of this section describes the JCALS system design, 
implementation, components, and future developments. 

a. System Design 

JCALS is an information management system that will support acquisition, 
logistics support, engineering, manufacturing, configuration control and materiel 
management processes throughout the life-cycle of a weapon system. It uses multi¬ 
weapon system IWSDBs and Global Data Dictionary and Directory (GDD/D) Services 
that are connected by a wide area computer network. The interface for users is the 
JCALS Workbench that provides an environment to access all of JCAL’s functionality 
transparently to the user. JCALS was designed within the CALS requirements and CIM 
Technical Reference Model (TRM) architecture. It uses open systems standards, making 
it flexible and scaleable. (DoD MIL-HDBK-59B, 1994, pg. 34) 

The design specifications for JCALS indicate that it can have a bi¬ 
directional interface with Contractor Integrated Technical Information Services (CITIS) 
and Electronic Data Interchange (EDI) suppliers over a Wide Area Network (WAN). 
CITIS is an information system furnished by a defense contractor that provides access to 
the technical data and information associated with a defense system contract to 
government acquisition managers and technical representatives. This bi-directional 
interface can be one or more of the four types listed below (DoD MIL-HDBK-59B, 1994, 
37); 

1. non-interactive data exchange using removable digital media; 

2. selected CITIS functions using dial-up or network access capabilities; 

3. on-line interface where data dictionaries are mapped to each other for 
transparent, seamless access; and 

4. fully integrated, JCALS site-type interface for which the contractor is furnished 
GDD/D services, software and if required, equipment. 
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b. System Deployment 

Presently JCALS is in prototype at six DoD sites; Marine Corps Logistics 
Base Albany, GA; Marine Corps Base Quantico, VA; Tinker Air Force Base (AFB), OK; 
Wamer-Robbins AFB, GA; Naval Surface Warfare Center (NSWC), Port Hueneme, CA; 
and the Army’s Missile Command in Huntsville, AL. 

JCALS also has four Technology Application Sites currently located at: 
Los Angeles AFB, Los Angeles, CA; Peterson AFB, Colorado Springs, CO; McClellan 
AFB, Sacramento, CA; and NSWC, Dahlgren, VA. If fully deployed, JCALS will 
eventually have 245 sites connected over the Defense Information Systems Network. 
Delivery of the first JCALS system is expected to begin in the first half of 1996. 

c. System Configuration 

The JCALS software is a suite of commercial off-the-shelf software 
(COTS) and Government Owned Software (GOTS) that are integrated by CSC with 
custom Ada code. Current COTS packages include: Oracle Corporation’s Trusted 
Oracle 7 database management system. Digital Equipment Corporation’s (DEC) 
Multilevel Secure Plus Operating System, ArborText Incorporated’s AdeptPublisher, and 
numerous utility and viewer applications. CSC states that COTS (which are designed into 
the X-Windows operating system to provide consistent user interfaces) currently make up 
about 95 percent of the JCALS software suite (Endoso, 1994, pg. 39). 

The GOTS portions of JCALS include a Workflow Manager application 
created in the Ada programming language, the Global Data Base Manager (GDMS), and 
the Reference Library. The workflow manager application provides a user tool for 
analysis using the principals of Business Process Reengineering involving digital data. A 
completed workflow will contain all the database links necessary between the individuals 
and technical data associated with a particular process. The Reference Library is a 
repository for publications, documents, engineering drawings and illustrations that are 
accessible to JCALS users through the Reference Library Search tool. Depending on an 
individual’s access rights, a user may either view or review and annotate any document 
contained in the Reference Library. 

A typical JCALS site will have a Fiber-optic Distributed Data Interface 
(FDDI) backbone ring with the JCALS engine consisting of the GDMS, Network 
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Processor and Internet Protocol Router. The JCALS work group consists of DEC Alpha 
workstation servers, X-terminal workstations, and various other peripheral devices. This 
hardware is interconnected by Ethernet cabling. Figure 1 depicts a typical JCALS system 
configuration. 

Presently, the only application developed by CSC that is operational on the 
JCALS infi'astructure is the Technical Manual Management System (TMMS). This 
system permits users to acquire, manage, and author technical manuals including the 
production of reproducible copies, in either digital or paper formats. The TMMS system 
integrates the common user interface (workfolder concept), workflow management 
application, and the GDMS access to technical data. (Gourley, 1995, pp. 20-21) 

d. Recent Developments and Future Enhancements 

Through each software upgrade to JCALS, performance enhancements and 
improved capabilities have been added to the different software modules. In JCALS’ most 
recent software upgrades, a PC client application and a basic interface to JEDMICS, and 
several other DoD information systems were added. Future JCALS enhancements will 
include integration of COTS applications (such as Adobe Systems Acrobat Press and 
Reader) and providing multimedia capabilities for the authoring and creation of Interactive 
Electronic Technical Manuals (lETMs). 
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Figure 1. JCALS System Configuration 

2. Joint Engineering Data Management Information and Control 

System 

The Joint Engineering Data Management Information and Control System 
(JEDMICS) is a CALS-compliant repository for the storage of engineering drawings and 
related technical data. It originates from the Engineering Data Management Information 
and Control System (EDMICS). EDMICS was a Navy program vrith a ten year firm-fixed 
price indefinite-delivery, indefinite-quantity contract. It had been awarded to PRC, Inc. of 
Reston, VA in 1989. The EDMICS program was validated as a program meeting the 
CALS initiative strategies and objectives in 1991 and selected as a tri-service program 
later that year. In 1993 EDMICS was chartered as a joint program by DoD and renamed 
JEDMICS. The Navy retained management responsibilities for the program. 

a. System Design 

JEDMICS consists of six subsystems that permit users on-line access to 
engineering drawings and related technical data stored in CALS data formats. The six 
subsystems (input, data integrity, index, storage, output, and remote output) follow a 
standard open system design in a client-server architecture. The subsystems are scaleable 
and compatible with existing applications and information systems at a particular 









JEDMICS site. JEDMICS supports the input and output of paper drawings, text pages, 
aperture cards. Computer-aided Design (CAD) files, magnetic tapes, optical players, and 
direct connections to and from other information systems. It maintains the drawings and 
technical data in the following CALS file formats; Raster, ASCII, binary, 2D/3D vector, 
SGML, IGES, and CGM. 

b. System Deployment 

Presently there are twenty-four JEDMICS sites installed at Navy, Army, 
Air Force, and Defense Logistics Agency sites. A typical JEDMICS site will include 
maintenance and logistics activities such as Naval shipyards, the Marine Corps logistics 
bases. Army depots. Air Force depots and Defense supply centers that require access to 
engineering drawings. 

c. System Configuration 

JEDMICS consists of GOTS and COTS software that are integrated 
through a JEDMICS Application Program Interface (API) that permits the software to 
operate in a C-2 level secure, client-server environment. The custom GOTS applications 
provide for indexing, retrieval, security, backup, archiving, import/export, and 
management reporting. The COTS applications include the Oracle database management 
system, UNIX operating system and various utility applications for viewing and converting 
the variety of data file formats. 

Current server platforms include Digital Equipment Corporation (DEC) 
VAXA^S mainframe computers, Silicon Graphics and Hewlett Packard workstations. 
Client platforms include workstations and microcomputers from DEC, Sun Microsystems, 
Intergraph, Silicon Graphics, and numerous desktop microcomputers running various 
operating systems and application programs. JEDMICS uses Kodak optical jukeboxes as 
the storage device for engineering drawings and technical data. 

d. Recent Developments and Future Enhancements 

The JEDMICS API developed in 1994 permits JEDMICS to operate with 
other information systems in Local Area and Wide Area Network environments. In 
October 1994 the interface between JEDMICS and JCALS was demonstrated when a user 
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on a JCALS workstation was able to query and retrieve engineering drawings from a 
JEDMICS repository. 

As the military services digitize their technical data in CALS data formats, 
JEDMICS hopes to become the standard repository for all technical data, including 
technical manuals. Continued improvements to JEDMICS’ interface and access methods, 
will allow DoD and private sector engineering, planning, logistics, training, and 
maintenance organizations to share the same techmcal data throughout the life-cycle of a 
defense system. 
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III. CALS DATA FORMAT SPECIFICATIONS 


This chapter presents the CALS specifications and standards related to the 
publishing of technical data. The word “publishing” means to prepare and issue (the 
assumption is printed material) for public distribution or sale. Under the CALS initiative, 
the specifications and standards relating to the production of technical data has automated 
the exchange of illustrations, drawings, text, images, and graphics used in technical 
documentation. This chapter describes four of the most significant military specifications 
and standards relating to producing technical data and publishing technical manuals. 
These specifications are known as the CALS Data Format Specifications and are 
commonly referred to as the “28000 series specs,” 

A. MIL-D-28000A 

The MIL-D-28000A military specification is an example of a CALS 
standardization document that provides implementation guidance for an industry standard. 
It addresses the digital representation of product definition data using a subset of the 
Initial Graphics Exchange Specification (IGES) as defined by the American Society of 
Mechanical Engineers standard Y14.26M (Digital Representation for Communication of 
Product Definition Data). MIL-D-28000A’s full title is “Digital Representation for 
Communication of Product Data: IGES Application Subsets and IGES Application 
Protocols.” 


1. Purpose and Applicability 

This standard relates to the interchange of Computer Aided Design (CAD) system 
generated drawings between two applications fi'om two different software vendors. This 
section describes how MIL-D-28000A provides for this interchange through the definition 
of Classes, Application Subsets, and Application Protocols. 

a. Classes and Application Subsets 

MIL-D-28000A specifies only five of all the possible classes within the 
IGES standard. These classes are: 
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• Class I, Technical Illustrations Subset; 

• Class II, Engineering Drawings Subset; 

• Class III, Electrical/Electronic Applications Subset; 

• Class rV, Geometry for Numeric Control Manufacturing Subset; and 

• Class V, 3D Piping Application Subset. 

The IGES standard is considered to be a voluminous standard with the 
flexibility of allowing a variety of ways to represent the same Computer Aided Design 
(CAD) model entity. CAD vendors usually only provide a subset of the IGES standard 
for use in their CAD applications. When entities are exchanged between different CAD 
applications, mismatches inevitably occur between IGES entities in use by the two CAD 
systems. 

The first four of the classes listed above explicitly specify the entities 
required for their Application Subsets. A provision in the standard is made for a 
“volunteer entity” for the purpose of recreating the environment of the transmitting CAD 
system on the receiving CAD system. (Garner, et. al., 1994, pg. 3-2) 

b. Application Protocols 

When interchanging product data using the IGES standard, the Application 
Protocol (AP) defines the user requirements for the applications based on the Application 
Reference Model. The AP is specific for a particular class of drawings and provides the 
means for how information is mapped into the required IGES entities. 

c. Vendor Support 

Most CAD application software vendors today provide some level of IGES 
compatibility with a translating routine. Vendor support for MIL-D-28000A is not as 
prevalent as for the full IGES standard, though some of the classes are supported more 
than others. Currently Class II, engineering drawings, and Class I, technical drawings, are 
the two most supported classes within MIL-D-28000A. There is at least one non-CAD 
software application, the Interleaf document publishing system, that provides support for 


32 



both the IGES standard and Classes I and II of MIL-D-28000A. (Gamer, et. al., 1994, 
pg. 3-7) 

2. Future of Standard 

This standard is dependent on the IGES standard version 5.1 and the American 
National Standard Y14.26M of 1989. The CALS Evaluation & Integration Office works 
closely with the standards organizations through the organization’s CALS/IGES Special 
Interest Group. This group actively reviews proposed changes and makes inputs on how 
the standard can be improved through revisions. (Gamer, et. al., 1994, pg. 3-5) 

B. MIL-M-28001B 

This military specification was one of the most controversial parts of the CALS 
initiative when it was first issued in 1988. As a standardization document now in its 
second revision, it is intended to provide implementation guidance for the international 
standard ISO 8879, “Standard Generalized Markup Language (SGML).” This military 
specification today, has become widely accepted by software vendors and national and 
international defense industries. 

1. Purpose and Applicability 

MIL-M-28001B, “Markup Requirements and Generic Style Specification for 
Electronic Printed Output and Exchange of Text,” sets out the requirements for the 
delivery of page-oriented technical documentation in digital form. This specification’s 
intent is to ensure that documents, prepared with authoring tools compliant with the ISO 
standard, may be automatically stored, retrieved, interchanged and processed among 
differing computer hardware and software systems at government and contractor sites. 

The specification details the procedures and symbology for the markup of 
unformatted text using the SGML standard for the purposes of encoding and formatting 
technical publications using Document Type Definitions (DTDs). Further, the 
specification sets out the requirements for how technical documentation, encoded in 
SGML, can be printed in a format compatible with the existing military specification for 
technical manuals and technical publications, MIL-M-38784C. This output of SGML 
encoded text is accomplished by the creation of a Formatting Output Specification 



Instance (FOSI) based on MIL-M-2800IB’s Output Specification (OS). Specific details 
about DTDs, OS, and FOSI are presented in the section title “SGML Constructs and the 
Document Style Semantics and Specification Language” that follows. 

Appendix C of MIL-M-28001B provides information on how a review and 
comment capability can be incorporated into a SGML publishing environment. This 
capability is invaluable when documents in preliminary form must be sent by the contractor 
to the government for review before they can be issued in final form. (Gamer, et. al., 
1994, pg. 4-6) 

a. Advantages 

The chief advantage of this specification is its ratification of SGML as a 
means for the interchange of ASCII text data. With ISO 8879 being an international 
standard, it makes document production and management easier by offering a method of 
authoring, storing and managing documents without the constraints of proprietary 
computer hardware configurations and software applications. 

b. Military Handbook SGML 

Military Handbook SGML (MIL-HDBK-SGML) offers additional 
guidance for application of MIL-M-2800 IB and ISO 8879. Issued by the DoD CALS and 
EDI Office, it is currently in draft form dated 21 June 1993. It is expected to be issued in 
final form in 1995 and will be available from the NTIS in digital formats. The substantive 
portion of the handbook provides an overview of SGML from the perspective of how it 
fits within the CALS strategy and then provide sections that describe the following tasks 
for an SGML user; 

• Performing a document analysis 

• Developing a DTD based on a document analysis 

• Tagging textual information based on a DTD 

• Preparing a FOSI in accordance with the OS in MIL-M-28001B 

• Using the SGML Reuse Library and SGML Tagset Registry. (MIL-HDBK- 
SGML, 1993, pg. 1) 
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The SGML Reuse Library and SGML Tagset Registry have been created 
by the Electronic Publishing Committee of the CALS ISG to serve as the repository for 
SGML constructs used in CALS applications. The Reuse Library maintains SGML 
constructs such as DTDs (and fragments thereof) and FOSIs while the Tagset Registry 
maintains constructs such as elements, attributes, and entities. (MIL-HDBK-SGML, 
1993, pg. 86) The Navy has developed a Navy Baseline Tagset that includes tags for use 
with the technical manual specification MIL-M-38784C to minimize the proliferation of 
differing tags and duplicate definitions for tags. 

c. Vendor Support 

Numerous products that support SGML publishing requirements currently 
exist in mainframe, UNIX and Microsoft DOSAVindows operating environments. SGML 
applications to visualize the hierarchical nature of DTDs, create new DTDs, and convert 
WordPerfect and Microsoft Word document styles to DTDs have been in existence since 
1993. Complete SGML authoring environments allow the user to accomplish SGML 
publishing with varying degrees of ease of use. Public domain SGML parsers, and DTD 
creation software applications for the DOS operating system, are in existence and are 
useful for academic purposes and smaller SGML implementations. 

SGML publishing software vendors have implemented the ISO 8879 
SGML standard to their products with minor variations. These differences with the 
SGML parser result in DTDs and FOSIs created by one vendor’s application not 
successfully parsing or displaying in another vendor’s application. While these differences 
are minor in most cases, they only add to the fhistration of users when two applications 
that claim compliance with an international standard are not seamlessly compatible with 
each other. 

Vendors have been careful not to tie their product too closely to this still 
evolving military specification, lest the alienation of the civilian commercial market. Some 
of the most significant SGML implementations have occurred in the aviation, automotive 
and heavy equipment industries. Nearly all the major software vendors participate in the 
Electronic Publishing Committee of the CALS Industry Standards Working Group, which 
is the primary organization responsible for the development of MIL-M-28001. This 
committee reviews comments on proposed amendments and future revisions of the 
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standard that are generated by government and industry users of the standard. (Gamer, et. 
al., 1994, pg. 4-9) 

2. SGML Constructs and the Document Style Semantics and 

Specification Language 

This section describes tAvo SGML constmcts in greater detail and includes an 
example of a Document Type Definition and an example of a Formatting Output 
Specification Instance. This section concludes with a description of the Document Style 
Semantics and Specification Language and its future impact on publishing with SGML. 

a. Document Type Definition 

A document type definition is a SGML file that details the structure of the 
information for a particular document. Its creation is usually the result of a group effort 
among individuals having adequate working knowledge of SGML and familiarity with a 
certain type of document, a technical manual for instance. The group begins document 
analysis by ignoring the formatting characteristics of the document and only studying how 
information within the document is stmctured. Only then will the group be able to begin 
to create a DTD. 

The DTD is an ASCII text file that contains the declarations, or elements, 
that describe how the information within a document is stmctured. The DTD is written 
using SGML syntax and formatting and must be parsed by a ISO 8879 compatible 
validating parser^ before it may be used. Each of these elements will become tags in the 
SGML instance file indicating the start and finish of a particular segment of information 
within the document. The elements in the DTD may also have attributes associated with 
them. These optional attributes provide a means to detail the possible values, including a 
default value, for an element. Figure 2 (top) shows a DTD for an office memorandum. 
The actual memorandum, as an SGML document instance, is shown in Figure 2 (bottom). 
In summary, the DTD defines what type of document is being modeled, which elements 
are permitted, how the elements are sequenced, and what attributes are possible for each 
element. 


^ A validating parser is a program that reads a DTD and checks whether errors are present and provides a 
report if they are. (van Herwijnen, 1994, pg. 278) 
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b. 


Output Specification 


The purpose of the Output Specification (OS) is to provide a means to 
exchange the style and formatting information among SGML publishing systems. The OS 


<!- Lines that start and end with two dashes are comments. -> 

<!-- This is a DTD for an office memorandum --> 


<! ENTITY % 
<!- 

doctype “MEMO” 
ELEMENTS 

MIN 

CONTENT 

> 

-> 

<!ELEMENT 

%doctype; 


({TO & FROM), SUBJ, BODY, CLOSE) 

> 

<! ELEMENT 

TO 

-0 

(#PCDATA 

> 

<! ELEMENT 

FROM 

-O 

(#PCDATA) 

> 

<!ELEMENT 

SUBJ 

-o 

(#PCDATA) 

> 

<!ELEMENT 

BODY 


(PARA)* 

> 

<! ELEMENT 

PARA 


(#PCDATA 1 LIST)* 

> 

<! ELEMENT 

LIST 


(#PCDATA) 

> 

<! ELEMENT 

CLOSE 


(#PCDATA) 

> 


<MEMO> 

<TO>Robert Smith 
<FROM>John Jones 
<SUBJ>Company Picnic 
<BODY> 

<PARA>Here are my ideas for activities at Saturday’s picnic: 
<LIST>Volleyball, Softball, Horseshoes, Square Dancing.</LIST> 
<PARA>Let me know what you think? 

</BODY> 

<CLOSE>Regards, John</CLOSE> 

</MEMO> _ 


Figure 2. Document Type Definition and Corresponding SGML Document Instance 
document type definition describes how the Formatting Output Specification Instance 
(FOSI) should be created for documents that have their source data tagged according to a 
DTD. 

The FOSI specifies the layout, formatting, and styles for the displaying of 
SGML encoded documents in a page-oriented format using the publishing software that 
the FOSI was created on. A FOSI is written for a particular class of documents that will 
be outputted in a particular format. For example, a FOSI created for use with technical 
manuals would be designed to conform with the format specified in MIL-M-38784C. It 
selectively takes any of the possible formatting and style characteristics fi’om the OS DTD 
and details how they are to be used for outputting a page of a technical manual. It is 
important to note that because FOSIs specify formatting information, they are necessarily 
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proprietary to the SGML publishing application or FOSI composition tool that was used 
to create the FOSI. 


c. Document Style Semantics and Specification Language 

A major shortcoming of the SGML standard is the lack of a definite 
method of formatting SGML encoded information. Consequently, software vendors have 
created and implemented FOSIs, an extension of SGML, to specify how SGML encoded 
information can be outputted in a particular format or style using their SGML publishing 
application. The DoD, with MIL-M-28001B and the OS, followed a similar route. It 
specified to developers how to use the OS to create FOSIs to output printed technical 
manuals, according to the technical manual specification. Formatting instructions in any 
form for use with a publishing application are necessarily proprietary. FOSIs are 
considered a necessity until a better method could be developed. 

The Document Style Semantics and Specification Language (DSSSL) is a 
language that allows the user to define how processing information, or formatting, should 
be associated with a SGML document. DSSSL is not SGML, but a query language that 
allows the user to identify SGML elements from the SGML document instance. Then the 
user may attach semantics such as formatting, style, and layout information to the 
elements from the DSSSL document architecture (van Herwijnen, 1994, pg. 226). 
Presently nearing ratification as an international standard, DSSSL permits the specification 
of formatting, style, and layout information without having ties to a particular publishing 
application. 

3. Future of Standard 

This standard has oscillated from being too specific and directive in nature to being 
too general. Revision A of this standard contained a DTD modeled after the technical 
manual specification at the time MIL-M-38784B. It also contained twelve derivative 
DTDs based on the master DTD. The current version of this standard, revision B, 
cont^ns only a sample DTD “template” that is intended to be a “toolkit” for DTD 
developers. If this DTD is taken literally, it will not yield a parseable SGML instance. 
(Gamer, et. al., 1994, pg. 4-1) Presently, the Computer Sciences Corporation (CSC) 
under the JCALS contract is designing a MIL-M-38784C conforming DTD titled the 
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“Quest-DTD” in the JCALS SGML authoring tool, ArborText Incorporated’s 
AdeptPublisher. 

Amendment 1 to MIL-M-28001B is expected to be made public in early 1995 and 
will primarily contain changes to the OS contmned in Appendix B. Future revisions of this 
standard should distance themselves from a specific class of documents and focus on 
DoD-specific implementation issues with the international SGML standard. Guidance 
concerning specific DTDs should be appended with the military specification that covers 
that particular class of documents or incorporated within MBL-HDBK-SGML. For 
instance, the DTD and FOSI for technical manuals should be contained in an appendix to 
MIL-M-37874C. Plans for issuing Revision C of MIL-M-28001B are underway, with its 
release expected in 1996 or possibly 1997. 

C. MIL-R-28002B 

This military specification was originally conceived because of an absence of 
national and international standards for the storage and exchange of large engineering 
drawings as raster graphics files. Now known as a standardization document, its current 
version is based on ISO standards and the Committee on Telegraph and Telephone 
(CCITT) recommendations. 

1. Purpose and Applicability 

This specification details how a contractor should deliver raster data to the 
government. It establishes the requirements for a standard interchange file format and the 
raster encoding scheme for raster data. Raster data or graphics are the digital 
representations of an image using picture elements. Picture elements have the 
information, such as lightness, darkness, gray-level and color, for a particular portion of 
the image they represent. The density of picture elements vrill determine how good the 
resolution of the image will be in raster data format and how large the raster data file will 
be for storage. (Gamer, et. al., 1994, pg. 5-1) 

MIL-R-28002B identifies two types of digital representations, or file formats, of 
raster data designated Type I and Type II. Type I raster files, also known as untiled raster 
files, are the result of digitizing an image to a single bitmap and then compressing it into a 
single file. Type II file format corresponds to the Open Document Architecture (ODA) 
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document as specified by ISO 8613, “Information Processing - Text and Office Systems - 
Open Document Architecture” standard. A Type II representation may consist either 
untiled raster data with the ODA parameters and data structuring or tiled raster data. 
Subdivision of an image into to non-overlapping segments, or tiles, yields tiled raster data. 
Each of the tiles is then handled as a separate picture element array. Tiled raster data is 
most often used in large mechanical drawings where there are large areas of open space. 
The compression standard specified by MIL-R-28002B for these types of file formats is 
Group 4 encoding as defined by the CCITT Recommendation T.6, “Facsimile Coding 
Schemes and Coding Control Functions for Group 4 Facsimile Apparatus.” 

a. Advantages 

The prime advantage of MIL-R-28002B is its commitment to follow 
developments with international standards and trends in industry. Whereas the origins of 
this standard were to fill a void for requirements for handling large engineering drawings, 
the CALS Policy Office has resolved to work side-by-side with industry by forming a joint 
Industry/DoD Tiling Task Group. The Tiling Task Group is headed by NIST and 
continues to monitor and develop issues related to MIL-R-28002B. (Gamer, et. al., 1994, 
pg- 5-5) 

b. Current Implementations 

This standardization document is used in several DoD programs. The 
Navy Automated Document Management And Publishing System (ADMAPS) uses the 
specification for document scanning, raster image display and raster image storage. The 
Air Force Engineering Data Computer-Assisted Retrieval System (EDCARS) and the 
Army Digital Storage and Retrieval Engineering Data System (DSREDS) have used the 
MIL—R-28002A standard for Type I raster graphics files. These raster graphics files have 
been successfully interchanged using MIL-D-1840A and displayed on the Engineering 
Data Management Information Control System (EDMICS), now known as Joint EDMICS 
(JEDMICS). (Gamer, et. al., 1994, pp. 5-2, 5-7) 
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c. Vendor Support 


Presently, InterLinear Technology’s Modular Electronic Document 
Information Solution is the only software application that supports both MIL-M-28002B 
Type I and II raster graphics files (Gamer, et. al., 1994, pg. 5-8). 

2. Future of Standard 

This standard is in its third revision and has been revised every two years since 
originally issued in 1988. It is anticipated that future revisions will follow international 
standards developments and industry trends. The portions of this standard relating to the 
Group 4 encoding compression and the ODA Raster Document Application Profile will be 
removed once they are incorporated by NIST into FIPS publications. 

D. MIL-D-28003A 

This standardization document was developed for the DoD by NIST in 
coordination with several industry groups. Titled, “Digital Representation for 
Communication of Illustration Data; Computer Graphics Metafile (CGM),” this standard 
is used when graphics or illustrations are interchanged between two systems in binary 
form. 


1. Purpose aud Applicability 

The CGM standard is published by the ISO (ISO/IEC 8632), the ANSI 
(ANSI/ISO 8632.1-4:1992), and the federal government (FIPS PUB 128) and defines the 
lowest level of drawing functionality required to reproduce a picture with a drawing 
application. Being a standard, CGM is defined to be independent of specific hardware 
platforms and software applications. A metafile is created by a drawing application 
generator and contains the information required for the picture data for the file. If the file 
is imported into a second drawing application an interpreter reads the information so that 
it may work with the file. To accommodate a variety of existing drawing applications, the 
CGM standard intentionally only specifies the output primitives and attributes and does 
not specify the semantics for picture data. This creates the requirement for an Application 
Profile. (Gamer, et. al., 1994, pg. 6-1) 
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With MIL-D-28003A, the DoD has defined how CGM files should be used with 
CALS applications. The Application Profile defines rules for the generator and interpreter 
for a drawing application that seeks compatibility with the CALS initiative. Although 
illustration data files can be interchanged in text, character and binary formats, this 
standard only approves the use of binary format for the encoding of CGM files. (Gamer, 
et. al., 1994, pg. 6-2) 

a. Advantages 

The primary advantage of this standard is its independence from particular 
hardware platforms such as monitors, printers, plotters, cameras, and software 
applications such as drawing and publishing applications. CGM is considered to be the 
best format for illustration data when compared to raster (larger size and dependence on 
the resolution of the output device) and 2D IGES (larger size and slower speed). (Gamer, 
et. al., 1994, pg. 6-6) 

b. Vendor Support 

This standard with its Application Profile is considered a subset of the 
international and national CGM standard. Many vendors that claim CGM standard 
conformance, do not conform with MIL-D-28003A because of the lack of the Application 
Profile details necessary for use with CALS applications. Currently six software vendors 
(Ashton-Tate, Computer Support, Lotus Development, Micrografx, Hewlett-Packard, and 
Software Publishing) offer applications that can both import and export CGM files 
conforming to MIL-D-28003A. Numerous other vendors offer applications that can 
either import or export CGM files or can both import and export CGM files, but only in 
conformance with the previous version of this specification. DoD organizations planning 
to use a drawing application for CALS compliant illustrations should be certain that the 
application explicitly conforms with the import and export requirements of MIL-D- 
28003A. (Gamer, et. al., 1994, pp. 6-8, 6-9) 

2. Future of Standard 

This standard was first issued in 1988 and is currently in its first revision (1991) 
with amendment 1 (1992). A possible evolution of the CGM standard in the CALS 
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environment is the definition of “intelligent graphics.” This type of graphic will contain 
information related to the graphic, but not pertaining to the illustration itself For 
example, the requirement for attaching comments about the graphic with the illustration 
and version control information for the illustration could be attached to a graphic file 
through the use of SGML tags on the illustrations. (Gamer, et. al., 1994, pg. 6-6) 

The international CGM standard is planning to specify three different widely used 
application profiles (including the MIL-D-28003A Application Profile) in its next revision 
(Gamer, et; al., 1994, 6-4). This may alleviate the need for this standard if the 
international, national and federal CGM standards cover all the CALS specific illustration 
requirements. 

E. CALS TEST NETWORK 

The CALS Test Network (CTN) is an Air Force managed program used to 
perform testing of CALS standards and CALS implementations. CTN tests are performed 
by DoD and industry representatives at various testbeds at military laboratories and 
national laboratories. The results are published on the CALS Bulletin Board System 
(BBS) for review. The primary aim of these tests is to “demonstrate the CALS standards, 
test their effectiveness and identify needed improvements to the standards. Most of the 
current work to data on the CTN has been on data interchange standards, such as MIL- 
STD-1840A “Automated Interchange of Technical Information.” (Navy CALS RIC 
DTG, 1994, pg. 12-12) 

The next chapter describes the Evolved Seasparrow Missile Program and its 
application of the CALS initiative specifications and standards in the first contract of the 
weapon system program. 
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IV. EVOLVED SEASPARROW MISSILE PROGRAM 


This chapter describes the Evolved SEASPARROW Missile (ESSM) program. 
The ESSM is an upgrade of the RIM-7P SEASPARROW missile with added capabilities 
to counter anti-ship cruise missiles that have maneuvering capabilities. Background 
material on the weapon system is presented first, followed by a description of how the 
ESSM program office has applied the Continuous Acquisition and Life-cycle Support 
(CALS) initiative during the acquisition planning process. The chapter concludes with a 
description of the solicitation and source selection process for the first contract for the 
ESSM program: the Engineering and Manufacturing Development (EMD) Phase 
contract. 

A. BACKGROUND 

This section provides background material on the ESSM. It includes a description 
of the weapon system, a description of the program participants, and a description of the 
program schedule. 

1. Weapon System Description 

The original RIM-7 SEASPARROW missile programs for surface ships were 
outgrowths of the Naval Air Systems Command (NAVAIR) air-to-air SPARROW missile 
program. These programs included the Basic Point Defense Missile System (BPDMS), 
which employed the RIM-7M missile and the follow-on SEASPARROW missile system. 
This missile system later became known as the North Atlantic Treaty Organization 
(NATO) SEASPARROW Missile System (NSSMS), employing the RIM-7P missile. 
These weapon systems, while effective at first, were unable to keep pace with recent 
developments in anti-ship cruise missile technology. 

The ESSM is a surface-to-air missile that is launched from surface ships against 
incoming anti-ship cruise missiles with maneuvering capabilities. An enhancement of the 
RIM-7P missile, the ESSM will have improvements in its rocket motor, tail control 
surfaces, improved guidance section, and an upgraded warhead. 
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2. Program Participants 


This section describes the ESSM program participants within the DoN, allied 
nations, and potential contractors. 

a. Department of the Navy 

As stated previously, the SEASPARROW missile system was originally a 
NAVAIR program within the Department of Navy (DoN). The ESSM, however, will be a 
Naval Sea Systems Command (NAVSEA) program within the Theater Air Defense (TAD) 
Program Executive Office (PEO). Because portions of the RIM-7P missile will be used in 
the ESSM, configuration management and legacy technical data issues will need to be 
coordinated between NAVAIR Tactical Air PEO and the ESSM program office. 

Outside NAVSEA, several other DoN activities will have roles and 
responsibilities in the ESSM program. These DoN activities are listed below; 

• The Naval Air Warfare Center Weapons Station at China Lake, CA will be the 
Technical Director Activity and Source Selection Activity. It will be 
responsible for all technical aspects of the ESSM and will select the defense 
contractor for the ESSM. 

• Port Hueneme Division, Naval Surface Warfare Center (PHD-NSWC), Port 
Hueneme, CA will be the In-Service Support Engineering Agent (ISEA) and 
the Testing and Evaluation (T & E) Agent. As the ISEA, PHD-NSWC will be 
responsible for receiving any technical data associated with the program and 
distributing it to the other government program participants. It will also be the 
repository for technical data and program documentation for the life-cycle of 
the weapon system. As the T&E Agent, PHD-NSWC will coordinate and 
conduct development, live-firing, operational, certification testing, as well as 
evaluation for the ESSM. 

• Dahlgren Division, Naval Surface Warfare Center, Dahlgen, VA will be the 
Principal for Safety. It will be responsible for developing handling and storage 
and usage safety procedures for the ESSM and reviewing contractor delivered 
safety documentation. 

b. ESSM Allied Nations 

The SEASP ARROW missile program has been exported to eleven allied 

North Atlantic Treaty Organization (NATO) countries and Australia through the Foreign 
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Military Sales (FMS) program. These nations became known as the NATO 
SEASPARROW Consortium. 

The ESSM program will differ from the NATO SEASP ARROW missile 
program in that participating nations and defense contractors in their nations will share in 
the development and manufacturing of the weapon system in a workshare effort. The 
United States’ defense contractor who will act as the prime contractor will be responsible 
for the design and manufacture of the guidance and the warhead sections as well as the 
integration of the entire missile. The allied defense contractors will develop and 
manufacture the kinematic upgrades of the rocket motor and tail control section. 

These nations (Australia, Canada, Denmark, Germany, Greece, The 
Netherlands, Norway, Portugal, Spain, and Turkey) have formed an ESSM Steering 
Committee that will meet semi-annually to review progress on the weapon system 
program. Additionally, these nations will share in the costs of the program beginning in 
fiscal year 1995. They will provide military and civilian defense acquisition personnel to 
the ESSM program office. 

c. Potential Contractors 

With the shrinking of the US defense industrial base, there are presently 
only two potential defense contractors with the capability to deliver a weapon system such 
as the ESSM. These contractors are Hughes Missile Systems Company in Tucson, AZ 
and Raytheon Company, Missile Systems Division located in Tewksbury, MA. 

3. Program Schedule 

The ESSM program schedule for the EMD Phase contract is expected to be 
awarded in the May-June 1995 time frame. The EMD contract encompasses the delivery 
of technical data packages, analysis and test reports, and an in-service support engineering 
package. It also includes production representative All Up Round (AUR) missiles of the 
upgraded RIM-7P missile for conduct of developmental and operational testing. The 
contract also specifies the delivery of the MK 41 Vertical Launch System (VLS) Quad- 
Pack Canister. This is a specially designed container that will hold four ESSMs for DDG 
51, Flight IIA ships. 
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Following design reviews scheduled in 1996, the delivery of the first test article is 
expected in the first quarter of 1997. Development and certification testing will begin in 
the forth quarter of 1995 and continue into the next century. 

Following successful development testing of the ESSM and receipt of Secretary of 
the Navy approval for acquisition milestone III (which is projected to occur in May 1999) 
it is expected that the EMD phase contract will be modified for a Low-Rate Initial 
Production (LRIP) Contract (approximately 200 missiles) and eventually a Full-Rate 
Production (FRP) Contract (4,355 missiles). The LRIP and FRP contracts will be 
subjected to competitive bidding. 

B. ESSM ACQUISITION PLANNING PROCESS 

This section describes the Evolved SEASPARROW Missile Program Executive 
Office’s Continuous Acquisition and Life-cycle Support (CALS) Government Concept of 
Operations and Data Management Plan for technical data. These documents will comprise 
two of the annexes to the ESSM Master Program Plan (MAPP). The MAPP will be 
presented to the prime contractor in mid-1995 as Government Furnished Information 
(GFI) following award of the ESSM EMD phase contract. 

1. Government Concept of Operations 

The ESSM Program’s Government Concept of Operations (GCO) document is 
still in a draft version as of January 1995. Its highlights are detailed below. 

a. Scope and Applicability 

This GCO is intended for use by the prime contractor and any subsystem 
contractors in the ESSM’s preliminary design, engineering and specification design, and 
detail design. It applies to all technical data and information created by the contractors 
and the government during the life-cycle of the ESSM program. The GCO is provided as 
government furnished information (GFI) to potential offerors as guidance for the 
development of CALS capabilities. 
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h. Goals and Objectives 

The ESSM program office intends to acquire and manage data and 
information associated with the ESSM in digital formats in accordance with the CALS 
strategies. To transition the ESSM program toward the CALS vision, nations 
participating in the program must adhere to the following goals and objectives: 

• Employ Concurrent Engineering (CE) principles to create and store data once 
for use in many applications, thereby reducing development cycles and 
increasing efficiency; 

• Designate a single point of control for creation and maintenance of technical 
data that will be common to multiple users thus increasing quality, accuracy, 
and consistency of information; and 

• Use an integrated data base to provide seamless, automated access and 
interchange of data and information associated with the ESSM Program and 
participating defense industry users. 

c. Contractor's Approach to CALS 

The GCO details what information will be required in the Contractor’s 
Approach to CALS (CAC). Along with the information specified in MIL-HDBK-59B, the 
ESSM Program Office requested that several specific issues be addressed in the CAC. 
These issues were: 

• How an enterprise environment can be developed between the contractor and 
his subcontractors, suppliers, and vendors; 

• Determination of access rights, limitations, and responsibilities for CALS data 
and products among the contractor, subcontractors, and the Government; 

• Provision for the contractor’s CE approach (that integrates system engineering, 
design, manufacturing, and logistic support functions). Where information is 
required to be transferred among functional areas, key fimctional and data 
relationships between processes should be identified and discussed; and 

• A description of the infrastructure required to support the CE environment that 
generates, stores and delivers the weapon system data and information. 
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2 . 


Data Management Plan 


The ESSM program’s Data Management Plan (DMP) is in draft form as of 
Januaiy 1995, specific details on the DMP in its current form are presented below. 

a. Scope and Applicability 

The DMP documents how the Government intends to process and manage, 
in digital formats, the technical data and information associated with ESSM program. It 
defines the roles and responsibilities of Department of Navy activities participating in the 
ESSM program and how they will interface with other program participants. Details of 
the DMP are applicable to all entities that develop and provide data and information for 
the ESSM. 


b. Data Management Organization 

Overall responsibility for data management of the ESSM Data 
Management Plan rests vwth the NATO SEASPARROW Project Office Support 
Engineering Manager (SEM). This office coordinates the generation of any ESSM 
technical data and is be responsible for the planning and management of its use. The SEM 
is also responsible for supervising the development of technical manuals for the ESSM. 

Port Hueneme Division, Naval Surface Warfare Center (PHD-NSWC) 
Code 4R (Missile Systems Department) is designated the Data Manager for the ESSM 
program. It is responsible for development, implementation and maintenance of a 
technical data management system that will be able to handle ESSM techmcal data in 
digital formats. PHD-NSWC Code 4R, as the Data Manager, is responsible for entering 
all technical data received from the prime contractor and distributing it electronically to 
the various DoN activities participating in the program for comment. PHD-NSWC Code 
4R vidll also serve as the repository for technical data and ESSM documentation for the 
program. Code 5B (Information Technology Department) of PHD-NSWC is designated 
to provide technical support to accomplish this responsibility. 

c. Program Data Management 

The DMP indicates that the Integrated Data Management System (IDMS) 
will be used during the detail design stage of the EMD Phase of the program and is 
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planned to be used during the transition to production and support phases of the program. 
Specific details on how the IDMS will be used is presented in the next chapter. 

d. Data Responsibility 

The DMP contains an ESSM Data Responsibility Matrix that identifies 
data types in the following categories: Support Engineering Plans and Reports; Support 
Engineering Data/Summary, System Engineering Plans and Reports; Government 
Furnished Equipment Program Management/Contract Status; Financial Planning; and 
Conference Agenda/Minutes. Within each of these data type categories a variety of 
program documents are listed by Contract Data Requirements List (CDRL) number. Each 
of these documents are coded with one or more of the responsible DoN activities 
associated with the ESSM Program indicating whether that activity has “view only,” 
“comment/annotate,” or “recommendations/consolidation” responsibility. This matrix also 
lists the office code within the Project Office that has the final approval authority for a 
particular document. A typical document might be “view only by one to two activities, 
“comment/annotate” by six to eight activities, and “recommendations/consolidation” by 
one of the “comment/annotate” activities. The “comment/annotate” activity is usually 
either Naval Air Warfare Center Weapons Station at China Lake, CA for documents 
relating to technical issues; Port Hueneme Division Naval Surface Warfare Center for 
documents relating to testing, logistics, and configuration issues; Dahlgren Division Naval 
Surface Warfare Center for documents relating to safety issues; or the ESSM Program 
Office for documents relating to financial planning and program management. 

C. ESSM SOLICITATION AND SOURCE SELECTION PROCESS 

This section describes the CALS specifications and standards that are part of the 
ESSM EMD phase contract’s Statement of Work (SoW). It concludes with descriptions 
of certain line items within the SoW relevant to the CALS initiative. 

It is important to note the ESSM EMD phase contract Request for Proposal (RFP) 
fell within the 180 day “grace period” following the Secretary Perry’s memorandum 
“Specifications & Standards - A New Way of Doing Business.” This ‘ grace period 
permitted the waiver of the implementation of the policy changes for on-going solicitations 
or contracts. (DoD OSD, 1994, pg. 2) 
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The effects of the acquisition policy changes were evaluated by the ESSM 
Program Manager (PM). The decision was made to either alter the wording of the SoW 
where it called for the application of the CALS specifications and standards or request a 
two-year waiver for the use of the CALS military specifications and standards. These 
subtle changes in wording and the request for a waiver are detailed with the description of 
the pertinent CALS specification or standard. 

1. ESSM Specifications and Standards 

The ESSM program in concert with the Navy Standards Improvement Program 
has a goal to minimize the use of military specifications and standards if suitable 
commercial standards are available. The PM identified nearly 100 specifications and 
standards applicable to a weapon system acquisition such as the ESSM. In an effort to 
use performance specifications instead of military specifications and in an effort to reduce 
contract oversight responsibilities, the PM deleted 23 military specifications and standards 
and used 31 commercial standards. This left 43 existing military specifications and 
standards pertaining to the ESSM. These 43 military specifications and standards are 
related to the predecessor RIM-7P missile (11), ordinance safety (9), missile testing (6), 
and miscellaneous (17), including eight CALS military specifications and standards. 

The ESSM EMD contract’s SoW identifies eight CALS specifications and 
standards. These CALS specifications and standards can be fiirther categorized as CALS 
Standards, CALS Data Format Specifications and Product, Process, Data Integration 
Standards. Each of these categories are explained in greater detail below. 

a. CALS Standards 

CALS standards are two military standards intended to facilitate digital 
data interchange between the government and a contractor. These standards require the 
contractor to provide technical data to the acquisition managers Avithout linking it to a 
proprietary hardware platform or information system. These standards are described in 
further detailed below. 


(1) MIL-STD-974, Contractor Integrated Technical Information 
Services (CITIS). This standard defines how a contractor is to provide the government 
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online access to technical data related to a government contract. The standard provides 
guidelines that the contractor must follow for updating, storing, controlling, reproducing 
and distributing the digital data on CITIS. (DoD CALS & EDI Office, 1994, pg. 25) 

(2) MIL-STD-1840B, Automated Interchange of Technical 
Information.^ This standard defines digital formats that may be used by the contractor in a 
CALS environment when providing technical data to the government. Useful for the 
exchange of technical manuals, engineering drawings and other digital data, it addresses 
how users in two different computer hardware and software environments may share 
technical data. This standard provides specific guidance on file sets and formats, data file 
representation standards, and file naming conventions, as well as standard header 
information for file exchange. Although the example in the standard uses a nine-track 
magnetic tape for interchange media, the standard permits the government and its 
contractor to select a mutually agreeable interchange media. Typical interchange media 
includes mini-cartridge magnetic tape or optical storage disk and depends on the computer 
infrastructure and technical data interchange requirements for the program participants. 
(DoD CALS & EDI Office, 1994, pg. 25) 

b. CALS Data Format Specifications 

The CALS Data Format Specifications establish the requirements for the 
delivery of technical data to the government. Applicable for the delivery of vector 
graphics, ASCII text, raster image data, and graphics metafiles, these specifications are 
commonly known as the “28000 series specs.” The specifications were discussed in detail 
within Chapter III, “CALS Data Format Specifications,” and are listed below: 

• MIL-D-28000A(1), Digital Representation for Communication of Product 

Data; Initial Graphics Exchange Specification (IGES) Applications Subsets 
and Application Protocols; 


^The reader should note that this standard was not included in the ESSM EMD Contract’s SoW, but was 
presented here to provide a complete description of the two CALS standards. 
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• MIL-M-28001B, Markup Requirements and Generic Style Specification for 
Electronic Printed Output and Exchange of Text (SGML); 

• MIL-R-28002B, Requirements for RASTER Graphics Representation in 
Binary Format; and 

• MIL-D-28003A( 1), Digital Representation for Communication of Illustration 
Data: CGM Application Profile. 

c. Product, Process, Data Integration Standards 

Product, Process, Data Integration Standards are intended to foster an 
environment of integrated design, development and manufacturing where contractor 
entities can work together sharing the same technical data. These concepts are the core of 
the CALS initiative. It is left to the acquisition manager to structure a contract to 
encourage the contractor, through the use of incentives, to meet these goals while fulfilling 
the contract requirements. These standards are described in further detail below: 

(1) MIL-STD-499A, Engineering Management (Systems 
Engineering). This standard provides a basis for defining, performing, managing, and 
evaluating systems engineering processes related to defense systems acquisitions. Related 
to the fields of concurrent engineering, integrated product development and integrated 
process development, this standard requires a contractor to consider life-cycle support 
processes while developing a system for defense procurement. (DoD CALS and EDI 
Office, 1994, pg. 27) 

(2) MIL-STD-973(2), Configuration Management (CM). This 
standard requires consistent CM practices by a contractor when developing a system for 
defense procurement. (DoD CALS and EDI Office, 1994, pg. 27) The ESSM PM has 
requested and received a two-year waiver from the Milestone Decision Authority in order 
to apply this military standard to the ESSM EMD phase contract. 
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(3) MIL-STD-1388-1A(4) and ]VI1L-STD-1388-2B(1), Logistic 

Support Analysis Record (LSAR) and DoD Requirements for a LSAR. The LSAR 
standard requires contractors to simultaneously perform Logistic Support Analysis during 
the development of a defense system. This standard strives to give the DoD a unified 
method to require contractors to (a) make support requirements a critical part of the 
defense system design, (b) specify what the support requirements will be as related to the 
system design, (c) define what the support requirements will be when the system is used 
operationally, and (d) design and provide requirement support material for the defense 
system. MIL-STD-1388-2B(1) defines how the LSAR data should be delivered so that it 
may incorporated into manual logistic data and Automated Data Processing (ADP) 
systems. (DoD CALS and EDI Office, 1994, pp. 27-28) The ESSM PM with the new 
acquisition policy phrased the SoW language as “use the guidance of MIL-STD-1388- 
1A(4) and MIL-STD-1388-2B(1)” instead of directly requesting that the contractor 
adhere to the military standards. This nuance encourages the contractor to follow the 
military standard without specifically requiring him to apply the military standard. 

2. STATEMENT OF WORK 

This section provides details in the ESSM EMD phase contract RFP’s SoW on 
technical data and documentation and technical publishing related line items. 

a. Contractor Integrated Technical Information Services (CITIS) 

The ESSM PM is committed to conducting this weapon system acquisition 
within the requirements of the CALS initiative. The Contractor Integrated Technical 
Information Services (CITIS) is a database located at the contractor site that may be 
accessed by authorized acquisition management and technical oversight personnel of the 
federal government. The definition of the telecommunications solution for the CITIS is 
requested to be in accordance with the CITIS CALS standard (MIL-STD-974) and the 
Government Open System Interconnect Protocols (GOSIP) contained in FIPS PUB 146- 
1 . 
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b. Technical Manual Program 

The technical documentation for the ESSM EMD phase contract is to 
include three technical manuals; Theory of Operations Manual, ESSM Functional 
Description Manual, and Explosive Ordnance Disposal Manual. These manuals shall be 
developed under the requirements of the Technical Manual Contract Requirement 
(TMCR) and the CALS requirements. Additionally, the contractor is required to provide 
the source data required to update the technical documentation associated with Fire 
Control and Launcher Systems technical manuals that will be affected by the ESSM. 

This chapter has presented an overview of the ESSM program including 
specific details of how the ESSM program office applied the CALS initiative during the 
acquisition planning processes and source selection processes. The next chapter will 
present the information technology inffastrupfure available for management of ESSM 
technical data at PHD-NSWC, the Navy’s ISE 4 for surface ship weapon systems. 
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V. INFORMATION TECHNOLOGY INFRASTRUCTURE AT THE IN- 
SERVICE SUPPORT ENGINEERING AGENT 

This chapter presents the information technology infrastructure at the In-service 
Support Engineering Agent (ISEA) for the ESSM program. Port Hueneme Division, 
Naval Surface Warfare System (PHD-NSWC) has been designated the ISEA by the 
ESSM program office. This makes it responsible for numerous tasks relating to 
maintenance of the technical data for the ESSM during the life-cycle of the weapon 
system. As stated in Chapter IV, PHD-NSWC, in its role as the ISEA, will be the Data 
Manager during the procurement phases of the missile system. 

The information technology (IT) infrastructure and the information systems 
available at PHD-NSWC will be crucial factors in how well PHD-NSWC will be able to 
perform its role as the Data Manager for the ESSM Program. The ESSM Program 
Office’s objective is to acquire and manage technical data and documentation associated 
with the ESSM in digital formats in accordance with the CALS strategies. PHD-NSWC 
will thus be a proving ground for the CALS principals. 

The Integrated Data Management System (IDMS), an information system that 
allows users to access and process many types of technical data on integrated technical 
databases from a common computer desktop environment, is presented first. Then a 
description of how portions of the Joint Computer-aided Acquisition and Logistics 
Support (JCALS) System are planned to be integrated with the IDMS to form a more 
capable data management system is presented. 

A. INTEGRATED DATA MANAGEMENT SYSTEM 

The Integrated Data Management System (IDMS) originates from an information 
system designed to manage ordnance alteration (ORDALT) instructions and Engineering 
Change Proposals (ECPs) at PHD-NSWC. The development for this system, named the 
Automated Documentation System (ADS), began in 1988 and was funded by Naval Sea 
Systems Command (NAVSEA) Productivity Investment Funds. During the development 
and testing of ADS, a determination was made that ADS technology could be adapted to 
Technical Manual (TM) change processes. A second ADS was procured by PHD-NSWC 
and parallel development began for integration of a technical manual processing 
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functionality. During the subsequent development of the two ADSs, a number of 
similarities between the two efforts were identified. This resulted in the decision to 
combine the two development efforts. The two systems, with the addition of a software 
module to manage Contract Data Requirements List (CDRL) in 1992, were renamed the 
Integrated Data Management System (IDMS). Development and implementation 
responsibilities for DDMS were consolidated at PHD-NSWC Code 5B00 (Technical Data - 
now Information Technology Department). A fully operational IDMS was developed by 
Scientific Applications International Corporation (SAIC) and the system has been 
operational since 1993. Version 2.1 is the current version. A second phase for IDMS 
development is planned with added functionality and further integration with other 
information systems. 

1. System Design 

IDMS’ software applications have been integrated using a three-layer architecture 
concept. The inner-most layer is considered the system layer, consisting of the operating 
system and network management utilities. The middle layer is the support layer. It is 
comprised of six application components; (1) the Visual Programming Environment, (2) 
the Interface Manager, (3) the System Adnunistration Manager, (4) the Electronic Mail 
and Bulletin Manager, (5) the Technical Publishing System, and (6) the Report Manager. 
The outer-most layer represents the application layer. It consists of the following nine 
user functions: (1) Document Manager, (2) Distributed Software Backplane, (3) Report 
Generation, (4) System Administration, (5) Tracking, (6) Review and Edit, (7) Review 
and Comment, (8) Graphical User Interface, and (9) Electronic Mail and Bulletin 
Interface. While helpful in understanding how IDMS’ applications are integrated in this 
current version, it is not certain whether this three-layer architecture will be maintained in 
future phases of IDMS’ development. (PHD-NSWC IDMS User’s Guide, 1994, pp. C- 
12, C-13) 

2. System Configuration 

IDMS makes use of an open system architecture to integrate commercial off-the- 
shelf (COTS) software applications in a client-server environment. An object-oriented 
application development environment. Visual Programming Environment (VPE) by 
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Market Focus Technologies, Inc., a division of SAIC, was used to integrate IDMS’ 
various software applications. The remainder of this section will describe IDMS’ 
Hardware and Networking Platform, Software Platform, and User Types. 

a. Hardware and Networking Platforms 

IDMS consists of multiple servers, workstations, and personal computers 
(PCs). The IDMS servers store a particular type of document created from within IDMS 
or obtained from another source. They provide users on-line access to a document 
through a client-server access. Each server is connected to local area and wide area 
networks, the Central Database Server, and other IDMS servers using thick Ethernet 
cabling and the TCP/IP protocol. The Central Database Server allows other servers to 
access a central repository for all the life-cycle and routing information for a particular 
type of document. IDMS workstations are intended for users with management 
responsibilities for a particular type of document. They permit users the most 
functionality. An IDMS workstation is connected to the IDMS servers using thick 
Ethernet cabling. IDMS servers and workstations at PHD-NSWC are either Hewlett 
Packard (HP) 9000 series, or Sun Microsystems SPARCstation hardware. A typical 
IDMS user will access IDMS through a desktop PC using an X-terminal emulation 
software application. This permits the user to become a client on one of the IDMS servers 
and thus run IDMS applications on his desktop PC. A typical PC at PHD-NSWC is a 386 
or 486 IBM compatible PC with four to eight MegaBytes (MB) of Random Access 
Memory, 180 or larger MB hard drive, fourteen inch or larger Super Video Graphics 
Array (SVGA) color monitor, Ethernet adapter card for local area access, and a 14.4 
Megabit-per-second (Mbps) modem for wide area access. Figure 3 depicts the Integrated 
Data Management System Hardware and Network Platforms. 
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Figure 3. Integrated Data Management System 
h. Software Platform 


IDMS has been implemented as an integration of the UNIX operating 
system and the X-Windows client-server environment with numerous commercial X- 
Window desktop applications and database engines. IDMS workstations use either the 
HP-UX or SunOS UNIX operating systems. Some of the X-Windows commercial 
applications include: Interleaf s Interleaf 5 desktop publishing application. Worldview 
document interchange application, Printerleaf document printing application; Novell’s 
WordPerfect 5.0 desktop publishing application; and Xerox Imaging System’s ScanWorX 
document scanning application. The database engines used in EDMS include Sybase’s 
Relational Data Base Management System (RDBMS) and Oracle’s RDBMS, version 7.X. 

Desktop PCs at PHD-NSWC that can function as clients on IDMS use 
Microsoft DOS version 6.2 and Windows for Workgroups version 3.1 for their operating 
systems. The local area network access is provided by Novell NetWare, which provides 
File Transport Protocol (FTP), telnet, and E-Mail capabilities. The X-Windows emulation 
application for IDMS varies among the following applications: EXCEEDW, WQR X, or 
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PC XVIEW. The TCP/IP protocol stack for IDMS is either Microsoft’s TCP/EP from 
Windows for Workgroups or WQR TCP/IP. Each desktop PC at PHD-NSWC also has 
an array of single-user desktop software applications such as word processing, 
spreadsheet, graphic presentation and drawing applications. These are selected according 
to each user’s preference and do not appear to conform to any type of standard set by the 
Information Technology Department at PHD-NSWC. 

c. User Types 

IDMS was conceived for two types of users: View and Edit users and 
Review and Comment users. View and Edit users are managers and technical writers who 
are responsible for editing technical documents such as technical manuals, technical 
bulletins, and advance change notices. These users may create documents on EDMS 
workstations at the central document processing area and route them to Review and 
Comment users who use their desktop PCs at their assigned work areas. 

Review and Comment users are engineers and logisticians who review the 
various types of technical documents. These users may not alter a document that is routed 
to them, but they may add their recommendations and comments to a document by 
attaching electronic notes to the document using the Interleaf Worldview application. The 
electronic notes are stored in a local working file and returned to a View and Edit user 
once the document review has been completed. 

3. System Functions 

This section describes the functionality of IDMS from the perspective of the two 
user types. The information in this section is taken from the respective user guides for 
EDMS View and Edit users and Review and Comment users. 

a. Technical Publishing System 

The Technical Publishing System (TPS) function of EDMS allows a View 
and Edit user to start either the Interleaf 5 or WordPerfect 5.0 desktop publishing 
applications. If a View and Edit user intends to route a technical document for review, it 
must be processed by the Interleaf Printerleaf function and it must reside in an Interleaf 
Book. The Printerleaf function prepares a print image file for an Interleaf document that 
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becomes a static copy of the document and cannot be edited directly. The Interleaf Book 
function serves as a filing cabinet metaphor for storage of the Printerleaf version of the 
technical document and makes it accessible to other users if necessary. If WordPerfect 
documents need to be routed, they are first converted to Interleaf format and then 
processed as discussed earlier. 

Currently there are no plans to integrate the Interleaf 5 <SGML>™ CALS- 
compliant publishing system and the associated CALS-compliant, SGML-based 
applications into IDMS. The primary reason for not pursuing this logical upgrade for 
DDMS is the refusal of Interleaf to sell their publishing system without PHD-NSWC 
purchasing their application integration services. Their cost for this does not seem 
justified. System integrators at PHD-NSWC are capable and able to perform the 
integration of Interleaf 5 <SGML>™ at a more reasonable cost. This situation will mean 
that IDMS will not receive a CALS-compliant publishing system. 

b. Document Routing and Review 

The Document Routing System is a custom application created by SAIC 
that permits a View and Edit user to route a document to Review and Comment Users. 
View and Edit users may assign an entire technical document or portions of a technical 
document to one or more reviewers, set a due data for the review, and create a report of 
the workload for a particular reviewer. This application does not contain any type of true 
workflow generation capabilities. Instead it provides a simplistic “out-and-back” routing 
capability. The View and Edit user is presented with a list box of potential groups and 
individual users within each process flow at PHD-NSWC. These process flows include 
ECPs, ORDALTS, CDRLs, and correspond to Interleaf filing cabinets. A manager selects 
one or more Review and Comment user(s) to whom the technical document should be 
routed according to the process flow. This system also allows a manager to de-route a 
document and alter the due data for a document that has been routed to IDMS Review 
and Comment users. 

The Review and Comment users perform their functions by selecting the 
Review button from the IDMS desktop. This act launches the Interleaf Worldview 
application that permits a Review and Comment user to view an Interleaf document and 
submit his comments on the technical document by attaching electronic notes to the 
document. This is a two-step process where the Review and Comment user opens a blank 
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electronic note and types his textual comments, then iconifies the electronic note, and 
drags it to the relevant section of the document. 

c Contract Data Requirements List Definition, Tracking, and 
Review 

Contract Data Requirements List (CDRL) Definition and Tracking are two 
separate functions on an IDMS View and Edit user desktop. The Definition function 
allows a View and Edit user to either create a new CDRL or update an existing CDRL. It 
also permits a user to indicate the recipients, types, and quantities of CDRL deliverables in 
the CDRL database. The Tracking Function permits a user to monitor the status of 
CDRL items for a selected contract. The CDRL Review function rests on a IDMS 
Review and Comment user desktop and allows one to view a “read-only” CDRL form and 
to attach comments using the Interleaf Worldview application. 

d. Document and CDRL Comment Merge 

The Document and CDRL Comment Merge system permits a View and 
Edit user to incorporate the comments from Review and Comment users on a technical 
document or CDRL. The electronic note in Interleaf Worldview is opened and a “cut and 
paste” operation is performed onto the technical document or CDRL form using either the 
Technical Publishing System or CDRL definition system, respectively. 

e. Return, Mailbox, and Utilities 

The IDMS Return function permits a Review and Comment user to return 
a technical document or CDRL to a View and Edit user after completion of his review 
responsibilities. The Mailbox function provides standard E-Mail capabilities to both types 
of IDMS users and is the primary method for View and Edit users to notify Review and 
Comment users of a their workload. The IDMS Utilities functions include a calendar 
program, electronic calculator, floppy disk utility, graphical user interface controls, 
password utility, and the ScanWorX document scanning application. 
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B. INTEGRATION OF IDMS WITH JCALS 


This section describes the planned effort to integrate the Integrated Data 
Management System (IDMS) with the Joint Computer-aided Acquisition and Logistics 
Support (JCALS) System. 

1. Background 

The concept of a common desktop environment for the ESSM Program that 
permits users to interact with other program participants and permits users to access 
program technical data and documentation is a stated objective of the Integrated Logistics 
Support (ILS) Manager for the ESSM Program Office. It is thought that such a desktop 
environment, with common software applications and uniform access to program technical 
data and documentation in digital formats, will foster a work environment that is superior 
to one where program responsibilities are carried out with paper-based processes. 

To satisfy this requirement, IDMS was proposed by PHD-NSWC as a possible 
candidate for a common desktop environment. IDMS had the advantages of being an 
almost fully implemented system. It had demonstrated functionality in CDRL definition, 
tracking, and review. It also could operate on a desktop PC. Some of IDMS’ 
shortcomings included its heavy dependence on the proprietary Interleaf desktop 
publishing application and its associated Printerleaf and Worldview applications. It also 
lacked a true workflow manager application. 

The JCALS system should be considered the future for the concept of a technical 
data management system with a common desktop environment. Still undergoing 
prototyping and development, the first operational systems are expected to be delivered in 
the first half of 1996. 

In January of 1995, IDMS was demonstrated on the JCALS prototype site at 
PHD-NSWC. For the purposes of the demonstration, the IDMS icon was available on a 
JCALS workstation and provided access to the IDMS server in a window on the JCALS 
desktop. An IDMS View and Edit user then accessed a sample document and assigned it 
for review to IDMS Review and Comment users locally at PHD-NSWC and remotely at 
the Marine Corps Logistics Base (MCLB) in Albany, GA. The IDMS Routing and Mail 
systems were used. The Review and Comment users locally and at MCLB received 
notification of the document awaiting review by E-Mail. They then accessed the sample 
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document and made their comments for demonstration purposes using editing tools locally 
available. The document was then returned to PHD-NSWC and the sample comments 
were incorporated by the View and Edit user into the document. Finally, the annotated 
sample document was forwarded, for printing using JCALS, to the Defense Printing 
Service which is co-located with PHD-NSWC at the Naval Construction Battalion Station 
in Port Hueneme, CA. This comprehensive demonstration proved that a legacy system, 
like IDMS, albeit only a couple of years old, could coexist with a newer information 
system such as JCALS. 

2. Implementation Plan 

Presently, the Information Technology Department at PHD-NSWC has initiated an 
integration effort to incorporate portions of JCALS into IDMS. PHD-NSWC intends to 
purchase the GOTS portions of JCALS, namely the Workflow Manager application, 
Global Data Base Manager, and Reference Library. CSC will provide integration support 
to PHD-NSWC on a fee basis as condition of the sale of the GOTS portions of JCALS. 
SAIC will perform the integration effort, with a projected completion data of the latter 
half of 1995. 

The most significant objective of the implementation plan is for the Interleaf 
desktop publishing application, and its associated Worldview and Printerleaf applications, 
to be useable with JCALS’ reference library, workfolder, and Workflow Manager 
application. IDMS and its associated CDRL definition, tracking, and review functions are 
a significant portion of the ISEA’s responsibilities during a weapon system program and 
are currently only implemented in Interleaf 5. The plan to integrate JCAL’s Workflow 
Manager into IDMS will provide IDMS View and Edit users the ability to perform 
Business Process Reengineering on current procedures. This may lead to the creation of 
workflows for the various types of processes expected to be performed by the ISEA 
during the ESSM contract. 

PHD-NSWC fully expects to migrate from IDMS to JCALS during the life of the 
ESSM contract. It is hoped that this intermediate step of integrating portions of JCALS 
with IDMS will ease PHD-NSWC’s and other ESSM Program participant’s transition to 
full JCALS in the future. 

This chapter has presented the Integrated Data Management System (IDMS), an 
information system that allows users to access and process many types of technical data on 
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integrated technical databases from a common computer desktop environment. IDMS’ 
strengths are its open client-server architecture, its integration with COTS applications, 
and its functionality in defining, tracking and reviewing CDRL data. These factors make 
IDMS a suitable candidate for integration with a system like JCALS that does not 
presently have the full functionality that is required at the awarding of the ESSM contract. 
Fortunately, IDMS has a generic enough nomenclature that allows it to endure as an 
information system that metamorphoses into a more capable integrated system. 

The next chapter presents the conclusions, recommendations, and issues for further 
research. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


This chapter presents some answers to the research questions addressed by this 
thesis and discusses several issues raised during the investigation that may warrant further 
research. The chapter concludes with specific recommendations related to the 
management of technical data for the ESSM program. 

A. APPLICATION OF THE CALS INITIATIVE TO THE ESSM EMD 

PHASE CONTRACT 

This section describes how the ESSM program office should continue to evaluate 
the applicability of the CALS initiative and especially its data format specifications to the 
ESSM EMD phase contract. 

1. Conclusions 

Given the recent changes in DoD acquisition policies that were brought on by 
Secretary of Defense, William J. Perry’s memorandum, “Specifications & Standards - A 
New Way of Doing Business,” the ESSM PM released the ESSM EMD phase contract 
RFP in a turbulent defense acquisition environment. It should be noted that the DoN, 
NAVSEA, and the ESSM program office certainly had their fingers on the pulse of the 
coming acquisition reforms. This was evidenced by the usage of the Navy Standards 
Improvement Program during the ESSM acquisition planning process. To summarize 
fi-om the material presented in Chapter IV, the ESSM program office evaluated over 100 
specifications and standards applicable to the ESSM program and deleted 23 military 
specifications and standards, substituted 31 commercial standards, and used 43 military 
specifications and standards including eight CALS military specifications and standards. 
Without question, the ESSM program office was out in front of the coming wave of 
acquisition reform. 

Although release of the ESSM EMD phase contract RFP fell within the 180 day 
“grace period” offered by the Perry memorandum for ongoing solicitations and contract 
negotiations, the ESSM program office sought to evaluate the application of the CALS 
initiative military specifications and standards. Subtle changes in wording and the request 
of a two-year waiver for two of the CALS standards relating to Logistic Support Analysis 
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Records (LSARs) indicate the ESSM PM’s willingness to comply with the spirit of the 
new acquisition policies called for in Secretary Perry’s memorandum. 

This research concludes that the ESSM program office should continue to monitor 
the applicability of the CALS initiative and its military specifications and standards in the 
current defense acquisition environment. Even though these CALS military specifications 
were applied to the EMD phase RFP and will likely be “called-out” in the contract award, 
they should continue to be evaluated by the ESSM program office for their applicability 
given the recent acquisition reforms. Until the DoD CALS & EDI Policy Office resolves 
how the CALS initiative will continue to exist given the current DoD acquisition 
environment, the ESSM PM should be prepared to reissue and possibly modify the EMD 
phase contract RFP if it deems that this is a prudent course of action. 

This position is especially true when considering the CALS data format 
specifications that were presented in Chapter III. DoN activities participating in the 
ESSM program are unfamiliar with handling technical data in CALS-compliant formats 
such as SGML. Specification of contractor-delivered textual data in SGML will only 
present new challenges for the DoN activities that are responsible for reviewing and 
commenting on the technical data. 

2. Issues for Further Research 

This investigation determined that the changes in acquisition policies called for in 
Secretary Perry’s memorandum placed an enormous burden on acquisition managers to 
seek performance or commercial standards that were equivalent to military specifications 
and standards. With this policy change, acquisition managers must not only be familiar 
with current military specifications and standards and how they are applied to a defense 
system procurements. Now, time consuming and manpower intensive investigations into 
industry practices and non-government standards must also be completed during the 
acquisition planning process. Further study in this area should be directed at developing 
some type of evaluation framework or methodology for comparing current military 
specifications and standards to performance, commercial, or non-government standards. 
Without such an evaluation framework or methodology, the alternative will be an longer 
acquisition time lines. 
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B. EVFORMATION TECHNOLOGY INFRASTRUCTURE AT THE IN- 

SERVICE SUPPORT ENGINEERING AGENT 

This section presents conclusions on several issues that have an impact on the 
Navy’s surface ship weapon system In-service Support Engineering Agent’s (ISEA) ability 
to perform its mission. Several issues that this investigation determined warranted further 
research are also presented. 

1. Conclusions 

The ISEA is the one Navy activity that has to “live” with the decision specifying 
what format technical data for a weapon system is delivered by a contractor. It is not an 
overstatement to assert that the effectiveness of the ISEA hinges on a decision specifying 
the format of the contractor-delivered technical data made during the acquisition planning 
process. In a budget climate where declining resources are the norm, it is unlikely that the 
funding to accomplish a conversion of technical data from a legacy format to a more 
useable format will ever be available. Such efforts, if necessary, will need to be funded 
from the I SEA’S operating funds. This situation makes the specification of technical data 
formats even a more important process during acquisition planning. 

The information technology (IT) infrastructure at the Navy’s weapon system 
ISEA can and should have an impact on how an acquisition manager specifies the delivery 
weapon system technical data. Currently the IT infrastructure at Port Hueneme Division, 
Naval Surface Warfare Center (PHD-NSWC) is a heterogeneous hardware and software 
environment. It reflects the diversity of the various types of technical data specified 
during a weapon system program’s life-cycle. Development of information systems, such 
as the Integrated Data Management System (IDMS), indicate the desire of PHD-NSWC 
to standardize on an open architecture for computer workstations, PCs, commercially 
available software operating systems (UNIX and X-Windows), and applications. While 
this strategy is admirable, it has not positioned PHD-NSWC to capitalize on the Navy’s 
efforts to specify delivery of technical data in CALS-compliant data formats, especially 
SGML. PHD-NSWC’s current effort to integrate IDMS with the government-owned 
software applications of JCALS is exactly the right course of action to follow. This 
should ease PHD-NSWC’s transition to the overall JCALS infrastructure and application 
suite. 
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One of PHD-NSWC’s major IT infrastructure shortcomings identified during this 
research, is its lack of a comprehensive enterprise-wide network architecture. Networking 
information systems with client-server architectures using Thick Ethernet cabling limits an 
information system’s potential and places a ceiling on the types of data that may be 
processed at a user desktop. As technical documentation such as technical manuals evolve 
to Interactive Electronic Technical Manuals (lETMs), the existing network architecture 
■will not support such resource intensive requirements. lETMs contain drawings, graphics, 
and multimedia features that are interactively linked and ivill require high data transfer 
rates to the technical writer’s client application from hypermedia servers. Additionally the 
existing network architecture makes it difficult to institute the processing of classified 
technical data and business-sensitive documentation. One alternative is to consider 
subdividing the existing network into sub-nets that serve functional processes within PHD- 
NSWC. 


2. Issues for Further Research 

The most pressing issue for further research related to PHD-NSWC’s IT 
infrastructure is its lack of an enterprise-wide network architecture. Clearly a significant 
effort must be made to design a network architecture that will support the requirements of 
PHD-NSWC. The second issue requiring further research is the development of 
workflows that reflect the ISEA’s functional processes being carried out with digital 
technical data formats instead of paper-based formats. Once the modeling of workflows 
has been accomplished, they should be created on JCALS’ workflow manager application 
and tested if possible. Once the integration of IDMS and JCALS is complete, it should 
facilitate the transition to accomplishing ISEA responsibilities entirely with digital 
technical data formats. 

C. DATA MANAGEMENT PLAN FOR THE ESSM PROGRAM 

This section points out several criticisms of the Data Management Plan (DMP) for 
the ESSM program as it stands in its current draft form. Specific recommendations on 
how the DMP could be improved to better reflect how the Government intends to manage 
technical data are also presented. 
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1 . 


Conclusions 


The Data Management Plan (DMP) as it stands in its current draft form is too 
specific in some areas and very general in other areas of technical data management. For 
example, the DMP focuses on the use of the Integrated Data Management System 
(EDMS) to such a degree that it explicitly describes the functionality of the system. 
However, the DMP does not address core technical data management tasks. One such 
task is how ESSM documentation will be controlled by the ESSM Data Manager. For 
instance, there is no discussion in the DMP of a document version numbering scheme. 
Additionally, the DMP in its current form does not address the exchange of classified 
technical data and business-sensitive ESSM documentation. Although it asserts that 
IDMS must be capable of transmitting and receiving classified technical data such as 
engineering drawings, specific security procedures have yet to be developed. 

2. Recommendations 

The core recommendations that this research makes are directed at how the Data 
Management Plan could be improved to reflect issues relating to the management of 
technical data. The draft Data Management Plan is an annex to the Master Program Plan 
(MAPP) which is expected to be completed by mid-1995. At that time the entire MAPP 
will be presented to the ESSM prime contractor. The draft Data Management Plan at the 
time of this writing was being reviewed and commented on by each of the Navy activities 
participating in the ESSM Program. It is a plausible conclusion that many of the issues 
presented below may already have been incorporated in the final version of the DMP. 
This investigation, because of time constraints, did not have access to the preliminary 
comments. 

The remainder of this section presents recommendations on issues that a DMP 
should address to fiilly describe to the contractor how the Government intends to manage 
technical data. 


a. Technical Data Working Group 

First, it is recommended that the ESSM PM establish a Technical Data 
Working Group that meets regularly to discuss technical data matters. Membership in the 
group should include representatives from technical, logistic, program management, and 
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information technology management fields. The Technical Data Working Group would be 
responsible for identification of technical data types, processes, and management systems. 
Each of these responsibilities is described below. 

b. Identification of Technical Data Types 

One of the first responsibilities of the Technical Data Working Group is to 
identify the various technical data types that will be used during the life-cycle of the 
weapon system. This begins with the determination of what legacy technical data exists 
and whether it will be used for the new weapon system. At this time, a decision must be 
made on whether to retain the legacy technical data in its current format or to convert it to 
a different format that takes advantage of current technology. An issue for consideration 
is how the new technical data will be identified if legacy data is used to generate new 
technical data? For instance, if a legacy engineering drawing is used as a starting point to 
create a new drawing for a weapon system, at what point is the new drawing considered a 
whole new drawing rather simply a modification of the legacy drawing? 

The Technical Data Working Group is also responsible for identifying what 
technical data types will be generated by the contractor. Ideally this responsibility is acted 
upon very early in the acquisition planning process, since it would constitute an input to 
the weapon system contract SoW and the generation of CDRLs. This responsibility 
requires complete familiarization of the CALS initiative military specifications and 
standards. Since the Secretary of Defense memorandum now directs that the CALS 
military specifications and standards be viewed as guidance by acquisition managers, this 
requires that working group members investigate performance, commercial, and non¬ 
government standards that yield technical data or processes that are equivalent to what the 
CALS military specifications and standards would have )delded. 

c. Identification and Description of Technical Data Processes 

Once the Technical Data Working Group identifies the technical data types, 
each of the necessary technical data processes should be identified and described. The 
perspective for identifying these technical data processes should be from the program 
participant’s responsibilities during management of the weapon system contact. The 
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description of how the technical data processes should be carried out should be as 
complete as possible. Below is a recommended list of sample technical data processes; 

• Data Submission is the process by which technical data is forwarded to the 
weapon system Data Manager. This process as a minimum should identify 
what methods and which protocols are to be used. 

• Data Access and Views refer to how the Data Manager will provide access to 
program technical data to other program participants. This process should 
identify how classified technical data and business-sensitive documentation may 
be accessed and viewed by program participants. It should include what rules 
are in effect and what viewer applications will be used for technical data and 
program documentation. 

• Data Routing is the process by which program technical data will be 
transferred among program participants. Transferring of technical data and 
program documentation refers to what method and which protocol will be in 
effect. It includes how classified technical data and business-sensitive program 
documentation will be handled. 

• Workflow Generation is the process of translating current acquisition 
processes into workflows using Business Process Reengineering principles, if 
this has not already been done. A complete detailing of who will be 
responsible for creating, monitoring, and canceling particular classes of 
workflows, what workflow applications vrill be used, and what workflow 
conventions will be followed should be included. 

• Data Manipulation and Enhancement refer to the processes by which technical 
data and program documentation is altered or commented upon. This process 
should include who will be assigned such duties, how this task will be carried 
out, and what application will be used. 

• Data Ownership and Storage will be the overall responsibility of the program 
Data Manager. It should address how technical data will be controlled (i.e. 
version control) and how it will be stored in a technical data repository. 

d. Technical Data Management Systems 

Technical Data Management Systems are the information systems that are 
projected to be used during the life-cycle of the weapon system program to handle 
technical data and program documentation in digital formats. This section should not 
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explain in detail how the data management systems will perform the necessary technical 
data processes. Instead it should address how the system will be administered and how 
the system will be deployed among program participants. The types of information 
systems can be categorized into legacy systems, CALS infrastructure modernization 
systems, and contractor furnished systems. These three types of systems are explained 
below: 

• Legacy systems are information systems that are currently in use or under 
development at Navy activities participating in the weapon system program. 
This section should acknowledge the existence of these systems and describe 
whether they are compatible with the program’s needs. Additionally, migration 
options to the CALS infrastructure modernization systems or to another 
information system should be discussed here. 

• CALS infrastructure modernization systems refer to the Joint Computer-aided 
Acquisition and Logistics Support (JCALS) system and the Joint Engineering 
Drawing Management Information Control System (JEDMICS). This section 
should address whether either of these systems are available for program 
participants or how program participants may eventually migrate their technical 
data and processes to these systems. 

• Contractor furnished systems refer to either the CALS military specification for 
a Contractor Integrated Technical Information Services (CITIS) system, or a 
proprietary contractor developed system, or a commercial off-the-shelf system 
if available. This section should acknowledge the existence of these types of 
systems and describe whether they are compatible with the program’s needs. 

This chapter has presented conclusions on why the CALS initiative and its 
data format specifications should be reviewed as to their applicability to the ESSM 
Engineering and Manufacturing Development phase contract. It should be recognized that 
a tremendous effort by ESSM program acquisition managers was put forth to developing 
and issuing the EMD phase contract RFP. Clearly these individuals were faced with 
challenging issues in a changing DoD acquisition environment. Application of the CALS 
military specifications and standards to this weapon system acquisition was a major step in 
the acquisition planning process. 

Conclusions on why the Navy’s weapon system ISEA should figure 
prominently when acquisition planners specify contractor-delivered technical data have 
also been presented. Issues requiring further research including the ISEA’s IT 
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infrastructure especially an enterprise-wide network architecture and reengineering of 
ISEA technical data processes have been described. It is hoped that the recommendations 
on how a Data Management Plan could be structured will be helpful to acquisition 
managers during the acquisition planning processes for fiiture weapon systems. 
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